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1.0  SCOPE 


1.1  IDENTIFICATION 


This  document,  Repository  Operations  and  Procedures  (CDRL  1470)  addresses 
STARS  RFP  SOW  Section  4.0  of  Delivery  Order  IR11  (Subtasks  11.3,  11.4, 
11.5,  and  11.7). 


1.2  PURPOSE 


A  brief  assessment  of  the  existing  prototype  capabilities  is  included  in 
this  document.  The  assessment  also  co/ers  the  contents  with  respect  to 
the  quality  and  consistency  of  the  components,  i.e.,  documentation  of 
component  ownership,  data  rights,  and  ITAR  Restriction  considerations. 
This  document  also  provides  candidate  terms  and  conditions  for  Government 
license  agreements  and  sample  forms  to  collect  data  required  to  operate 
the  repository.  The  samples  are  for  review/selection  by  the  component 
suppliers  and  repository  managers.  This  includes  license  agreements  for 
Government  developed  or  owned  software  where  the  Government  would  like 
to  limit  the  use  of  the  reusable  software  or  related  information.  The 
output  of  Task  IR11  is  expected  to  be  used  to  help  evolve  the  STARS  Re¬ 
pository  to  the  status  of  a  National  Repository.  This  document  also 
contains  a  set  of  recommended  procedures  to  help  in  the  operation  and 
maintenance  of  the  STARS  Repository  System. 


1.3  INTRODUCTION 


The  installation  and  user  procedures  of  individual  hardware  and  software 
products  used  to  build  the  current.  STARS  Repository  System  are  assumed 
to  be  included  as  a  part  of  the  individual  products.  This  document  defines 
high-level  operation  guidelines  and  procedures  for  the  STARS  Repository, 
i.e.,  this  document  is  written  to  give  all  current  or  potential  users  a 
quick  overview  of  the  repository  guidelines  and  procedures.  Referenced 
and  product  related  documents  should  be  examined  for  additional  detail. 

The  overview  contains  a  listing  of  key  references  that  can  be  reviewed 
for  a  better  understanding  of  the  concepts  of  the  STARS  Repository,  the 
definition  of  the  terms  used,  and  a  brief  assessment  of  the  current  re¬ 
pository  prototype.  The  conclusions  reached  in  preparation  of  the  as¬ 
sessment  are  the  basis  for  the  remaining  sections,  i.e.,  a  consistent 
method  of  collecting  information,  evaluating  candidate  components,  and 
managing  the  repository.  Consistent,  comprehensive,  and  automated 
procedures/processes  are  required  to  ensure  high  quality  contents  and 
reasonable  operating  expenditures. 
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2.0  REFERENCED  DOCUMENTS 


The  following  documents  were  used  in  the  generation  of  this  document. 


2.1  GOVERNMENT  DOCUMENTS 


FI  9628-88- R -0011 

DI-S-3591 

(none) 

(none) 

(none) 

(none) 

(none) 


The  STARS  Competing  Primes  Lead  Contract,  Request  for 
Proposal,  dated  6  November,  1987. 

Technical  Reports 

User's  Guide  to  DACS  Products  &  Services  (April  1987, 
RADC/COED,  Griff iss  AFB,  NY  13441-5700) 

DACS  Newsletter  (Volume  VII,  Number  2,  June  1988; 

DACS  Bulletin  (Volume  IX,  Number  1,  January  1989) 

DACS  Products  &  Services  Information  (March  1987 

DACS  Products  &  Services  Form  (March  1987) 


IBM  CDRL  0360 

IBM  CDRL  0370 

IBM  CDRL  0380 

IBM  CDRL  0390 

IBM  CDRL  0460 

IBM  CDRL  0470 

IBM  CDRL  0480 


Reusability  Guidelines  for  the  STARS  Program,  dated 
December  17,  1988 

Reusable  Component  Data  Analysis  for  the  STARS  Pro¬ 
gram,  dated  February  10,  1989 

Consolidated  Reusability  Guidelines  for  the  STARS 
Program,  dated  March  21,  1989 

Taxonomy  Observations  for  Reusable  Ada  Components  for 
the  STARS  Program,  dated  March  21,  1989 

Repository  Guidelines  for  the  Software  Technology  for 
Adaptable,  Reliable  Systems  (STARS)  Program,  dated 
February  25,  1988 

Long-range  Repository/Distribution  Plan  for  the  STARS 
Program,  dated  February  25,  1989 

Enhanced  Repository  Formal  Demo,  dated  February  24, 
1989 


IBM  CDRL  0490  Enhanced  Repository  Demo  Report,  dated  March  3,  1989 

IBM  CDRL  0500  Specifications  for  the  Prototype  Enhanced  Repository, 

dated  January  19,  1989 

IBM  CDRL  0510  Enhanced  Repository  Implementation  Improvement  Re¬ 
port,  dated  March  16,  1989 


Referenced  Documents 
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IBM  CDRL  0520 


Long  Terra  Configuration  Management  Plan  for  the  STARS 
Repository,  dated  March  17,  1989 


IBM  CDRL  0530  Implementation  of  the  Prototype  Enhanced  Repository, 

dated  March  16,  1989 

IBM  CDRL  0700  Recommended  Ada  Format  Guidelines  for  the  STARS  Pro¬ 
gram,  dated  October  18,  1988 

IBM  CDRL  1440  Practical  Aspects  of  Repository  Operations  for  the 

STARS  Program,  dated  January  10,  1990 

IBM  CDRL  1450  Repository  Policy  Development  Plan,  dated  November 

17,  1989 

IBM  CDRL  1460  Draft  Policies  and  Procedures  for  the  STARS  Reposi¬ 
tory,  dated  January  19,  1990 

IBM  CDRL  1540  Repository  Guidebook  (Draft),  dated  September  14, 

1989 

IBM  CDRL  1550  Repository  Guidebook  (Draft),  dated  January  31,  1990 

IBM  CDRL  1570  Filter  Prototype,  dated  January  24,  1990  (and  earlier 

releases  A,  B,  and  C) 

IBM  CDRL  1580  Taxonomy/Classification,  dated  January  19,  1990 

IBM  CDRL  1590  Repository  Prototype  System  Specification,  dated 

February  16,  1990 

IBM  CDRL  1600  Repository  Prototype,  Release  A,  dated  July  15,  1989 

(and  subsequent  releases  B,  C,  and  D) 


2.2  NON-GOVERNMENT  DOCUMENTS 


ORACLE_SQLREF  SQL  Language  Reference  Manual,  Version  5.1,  September 

1988,  Copyright (C)  1988,  Oracle  Corporation,  Belmont, 
California 

ORACLE_DBA  Oracle  Database  Administrator's  Guide,  Part  3601, 

Version  5.1,  Copyright(C)  1988,  Oracle  Corporation, 
Belmont,  California 

ORACLE_UTIL  Oracle  Utilities  User's  Guide,  Part  3602,  Version 

5.1,  Copyright (C)  1987,  Oracle  Corporation,  Belmont, 
California 

ORACLE_SQLLOAD  SQL  Loader  User's  Guide,  Part  3606,  Version  1.0,  June 

1987,  Copyright(C)  1987,  Oracle  Corporation,  Belmont, 
California 


Referenced  Documents 
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ORACLE_SQLFORM  SOL  Forms  Operator's  Guide,  Part  3301,  Version  2.3, 

December  1987,  Copyright (C)  1987,  Oracle  Corporation, 
Belmont,  California 

ORACLE_QUICK  SQL  Forms  Operators  Quick  Reference,  Version  2.3 

ORACLE_ERRCODE  Oracle  Error  Messages  and  Codes  Manual,  Part  3605, 

Version  1.0,  Copyright (C)  1987,  Oracle  Corporation, 
Belmont,  California 

ORACLE_VMS  Oracle  for  DEC  VAX/VMS  Installation  and  User's  Guide, 

Part  1001,  Version  5.1,  Copvright(C)  1988,  Oracle 
Corporation,  Belmont,  California 


Referenced  Documents 
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3.0  OVERVIEW 


The  prototyping  efforts  for  the  STARS  Program  have  produced  a  number  of 
deliverables  and  many  are  included  in  the  "Government  Documents"  on  page 
2  and  will  be  referenced  in  the  appropriate  paragraph  in  this  document. 
For  an  overall  understanding  of  the  Repository  Operation  and  Procedures 
the  following  references  (CDRLs)  need  to  be  reviewed  and  understood  by 
the  Repository  Staff,  i.e.,  the  individuals  responsible  for  the  opera¬ 
tion,  maintenance,  and  improvement  of  the  repository  system. 

•  Repository  Guidelines  (CDRL  0460) 

•  Long  Term  Repository/Distribution  Plan  (CDRL  0470) 

•  Long  Terra  Configuration  Management  Plan  (CDRL  0520) 

•  Practical  Aspects  of  Repository  Operation  (CDRL  1440) 

•  Repository  Policy  Development  Plan  (CDRL  1450) 

•  Draft  Policies  and  Procedures  (CDRL  1^60) 

•  Repository  Guidebook  (CDRL  1540) 

•  Repository  Filter  Prototype  (CDRL  1570) 

•  Repository  Prototype  (CDRL  1600) 

The  Repository  Staff  must  also  be  familiar  with  the  specific  roles  each 
is  expected  to  fill  in  the  operation  of  the  Repository  System.  This  in¬ 
cludes  specific  knowledge  and  skills  related  to  specific  operational  re¬ 
quirements,  e.g.,  tuning,  backup,  and  recovery  of  the  database.  Each 
product  or  component  used  to  build  or  maintain  the  repository  shall  have 
user  documentation  that  is  procured  or  produced  and  maintained  for  the 
Repository  Staff,  e.g.,  Database  Administrator's  Guide  (0RACLE_DBA) . 
Several  of  the  key  documents  are  listed  in  "Non-Government  Documents"  on 
page  3  that  are  also  required  for  the  Repository  Staff  and  Reusers. 

The  terminology  used  in  this  document  is  summarized  in  the  following 
paragraph  and  is  consistent  with  the  terms  used  in  the  referenced  items 
(CDRLs)  listed  above. 


3.1  TERMINOLOGY 


The  following  is  a  list  of  terms  and  definitions  used  in  this  report. 
The  terms  are  presented  in  a  descriptive  order  which  supports  the  re¬ 
lationship  between  the  terms. 

component  A  collection  of  related  work  products  to  be  used  as  a 

consistent  sat  of  information.  Software  work  products 
can  include  specifications,  design,  source  code,  ma¬ 
chine  code,  reports,  compilation,  units,  code  fragments 
and  other  components.  It  is  the  primary  object  type 
for  search  and  access  of  the  repository.  A  component 
is  defined'  as  related  work  products  and  one  or  mors 
ref erencea  components ,  e.g.,  a  set  of  integrated  com¬ 
ponents.  Also  referred  to  as  an  asset,  or  resource. 


part 


An  individually  selectable  element  of  a  component, 
such  as  design  documents,  source  code,  test  infarma- 
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tion,  and  data  rights.  While  a  part  may  be  copied  or 
browsed,  when  stored  in  a  repository  it  is  always  as¬ 
sociated  with  a  component. 

reuse  The  application  of  existing  solutions,  as  captured  in 

components,  to  a  problem  other  than  the  one  for  which 
the  component  was  originally  built. 

repository  An  element  of  the  software  engineering  environment  in 

which  software  work  products  and  information  about 
them  are  stored.  It  is  the  primary  support  element 
for  reuse.  A  repository  can  be  built  with  one  or  more 
libraries  of  components.  The  repository  system  shall 
have  the  capability  to  import  (or  export)  specific 
libraries  from  (or  to)  another  repository. 

repository  library  A  collection  of  reusable  components  that  require  spe¬ 
cial  handling,  e.g.,  access  control,  higher  level  se¬ 
curity,  privacy  requirements,  or  limited  access  during 
specific  software  development  phases.  Libraries  can 
be  replicated  in  one  or  more;  distributed  repositories 
but  a  master  repository  must  be  designated  for  each 
library  to  ensure  the  consistent  updating  of  the  com¬ 
ponents  in  each  copy  or  replication  of  the  library. 

repository  system  An  instance  of  the  software  engineering  environment, 

including  computer  hardware,  operating  systems,  soft¬ 
ware  tools,  standards,  and  procedures  that  together 
provide  a  complete  repository  capability.  These  ca¬ 
pabilities  include  acquiring,  storing,  managing,  re¬ 
trieving,  and  dispensing  software  work  products  and 
information  about  them. 

depository  A  repository  or  part  of  a  repository  whose  contents 

are  deposited  as  is,  with  few  or  no  constraints.  A 
depository  is  mainly  a  storage  facility.  Quality  and 
usability  are  unpredictable;  the  burden  is  on  the  user 
to  find  and  evaluate  useful  items. 

organized  repository  A  repository  whose  contents  are  documented  and  or¬ 
ganized  in  a  comprehensive  manner  as  components  and 
parts.  Finding,  reviewing,  and  extracting  components 
are  supported.  The  quality  and  usability  remain  un¬ 
predictable. 

filtered  repository  A  repository  whose  components  are  subjected  to  stand¬ 
ards  on  form,  content,  quality  and  consistency.  This 
may  not  be  a  physical  partition  from  an  organized  re¬ 
pository;  rather  it  could  be  a  documented  higher  level 
of  confidence  in  an  existing  organized  component. 

certified  repository  A  repository  whose  components  exhibit  the  highest 

level  of  confidence.  A  certified  component  supports 
the  proving  of  correctness  of  the  solution  that  reuses 
the  component.  Aspects  of  security,  ownership,  dis¬ 
tribution,  and  user  set  take  on  greater  importance  in 
a  certified  repository. 
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reuser  A  person  who  reviews  the  contents  of  a  repository  and 

extracts  components  for  reuse.  The  common  user  of  a 
repository.  Also  referred  to  as  a  user. 

supplier  A  person  who  places  components  into  a  repository. 

"  Also  referred  to  as  a  contributor,  submitter,  or 

owner. 

operations  staff  Persons  who  coordinate,  organize,  and  control  the 

contents  of  a  repository  and  have  the  day-to-day  op¬ 
erations  of  the  Repository  System  and  the  Repository, 
For  particular  responsibilities  staff  personnel  are 
referred  to  as  a  manager,  system  administrator,  li¬ 
brarian,  database  administrator,  repository  adminis¬ 
trator,  or  repositarian .  The  System  Administrator 
provides  a  first  level  help  to  other  users  for  Repos¬ 
itory  System  problems.  The  Librarian  provides  the 
first  level  help  for  problems  with  the  contents  or  the 
capabilities  of  the  Repository. 

topic  specialist  A  person  who  understands  the  repository  domain  and 

many  of  the  components  in  the  repository.  This  person 
gains  their  understanding  by  being  responsible  for  the 
evaluation  of  components  and  promoting  them  to  fil¬ 
tered  or  certified  status.  Also  referred  to  as  a 
domain  expert,  or  technical  consultant.  This  person 
frequently  provides  a  second  level  help  for  other  us¬ 
ers,  via  reference  from  the  librarian.  This  person 
need  not  be  a  member  of  the  operations  staff. 

filtering  The  act  of  evaluating  components  and  promoting  them 

to  filtered  status.  The  process  can  be  manual  and/or 
automated  but  the  librarian  makes  the  actual  decision 
to  add  new  components  and  remove  obsolete  components. 

gatekeeper  An  automated  capability  that  facilitates  filtering. 

This  capability  is  initiated  by  the  librarian  or  by 
someone  designated  by  the  librarian. 

evolution  plan  A  document  o'r  section  of  a  document  that  summarizes 

the  repository  system  capabilities  in  a  chronological 
order.  This  plan  will  be  on-line  to  provide  scope  and 
direction  information  to  potential  suppliers  and  re¬ 
users.  This  plan  should  correspond  to  actual  plans 
and  commitments  contained  in  documents  not  accessible 
to  the  repository  users,  e.g.,  repository  operations 
contract/reports . 

repository  manager  The  person  who  is  responsible  for  the  operation  of 

the  repository  system,  i.e.,  to  ensure  that  adequate 
hardware,  software,  and  operations  staff  are  available 
to  support  the  STARS  Repository  System.  The  manager 
also  approves  the  evolution  plan  developed  by  the  op¬ 
erations  staff. 


Overview 


7 


3.2  REPOSITORY  SYSTEM 


The  repository  requirements  are  defined  in  the  Repository  Prototype  Sys¬ 
tem  Specifications  (CDRL  1590),  in  the  Repository  Guidebook  (CDRL  1540), 
in  the  terms  and  conditions  of  the  repository  operations  contract,  and 
in  documents  referenced  by  these  documents.  Together  they  establish  the 
capacity  and  performance  criteria  of  the  repository.  The  following  par¬ 
agraphs  summarize  the  basic  requirements  and  responsibilities  for  the 
repository  system  (see  CDRL  1440  for  the  details  of  the  current  IBM  Team 
STARS  Repository). 

The  scope  of  the  responsibility  is  determined  by  the  contract  established 
for  the  operation  of  the  repository  system.  The  repository  manager  shall 
ensure  that  adequate  licenses  or  contracts  are  established  for  the  use 
of  commercial  products  required  by  the  repository  system.  This  shall  also 
includes  maintenance  contracts  for  all  products  that  the  operations  staff 
is  not  capable  of  performing  or  are  not  authorized  to  perform  under  the 
corresponding  pi'oduct  license  or  contract.  Where  maintenance  is  to  be 
performed  by  the  operations  staff,  adequate  tools  shall  be  included  in 
repository  system  to  analyze  and  correct  errors  or  failures  in  products. 
The  products  include  both  hardware  and  software  items  as  summarized  in 
the  following  paragraphs  and  shall  be  chosen  to  support  all  standards 
specified  by  the  STARS  Program,  e.g.,  test  components  adhering  to  the 
Standard  Query  Language  (SQL) ,  the  Standard  Graphical  Markup  Language 
(SGML),  and  the  Virtual  Operating  System  Interface  (VOSI). 

A  repository  system  evolution  plan  shall  identify  the  capabilities  and 
the  selected  hardware  and  software  products  by  name,  version,  and  release 
number.  This  plan  shall  be  maintained  by  the  repository  manager  and  be 
in  conformance  with  the  long  term  plans  of  the  STARS  Program,  i.e.,  with 
respect  to  capacity  and  performance  requirements,  to  industry  standards, 
and  to  time/budget  constraints.  The  plan  shall  cover  the  electronic  and 
hard-copy  storage  and  distribution  resources  in  detail,  e.g.,  permanent 
and  consumable  media  quantities.  This  plan  shall  also  assume  that  data 
or  other  forms  of  reusable  information  will  be  collected  and  provided  to 
the  repository  users,  e.g-,  tested  or  recommended  initialization  data  for 
products  such  as  terminals,  terminal  emulators,  and  network  bridges. 


3.2.1  HARDWARE 


The  central  computer  system  selected  shall  have  the  capability  to  support 
the  STARS  Repository  System  performance  requirements.  The  computer  system 
shall  have  sufficient  backup  capability  to  meet  the  response-time  and  the 
availability  requirements.  A  central  computer  system  includes  processors, 
storage  devices,  peripherals,  and  communication  devices.  The  term  central 
computer  system  is  used  for  a  single-site  repository  or  to  distinguish  a 
master  repository  site  from  one  or  more  distributed  repositories  in  the 
STARS  Repository  System,  e.g.,  the  distributed  repositories  can  contain 
shadows  of  libraries  copied  from  a  master  library  (CDRL  0470).  Additional 
description  of  the  repository  system  hardware  is  in  "Repository  System 
Hardware"  on  page  34. 
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3.2.2  SOFTWARE 


The  repository  system  is  assumed  to  support  an  Ada  Software  Engineering 
Environment  (SEE),  and  therefore  the  products  and  tools  listed  below  will 
have  to  be  augmented  or  tailored  to  address  non-Ada  Requirements.  The 
repository  system  evolution  plan  shall  cover  all  Ada  and  non-Ada  product 
requirements  including  the  tailoring  of  component  types  and  templates, 
e.g.,  the  format  and  syntax  of  required  prologues.  The  operations  staff 
shall  be  familiar  with  the  software  used  in  the  computer  system  used  by 
the  repository  system  but  also  have  and/or  be  familiar  with  the  hardware 
and  software  used  to  support  the  typical  repository  user,  e.g.,  terminal 
emulators  and  file  transfer  programs.  The  rationale  for  the  staff  having 
and/or  understanding  the  various  products  is  to  prevent  minor  changes  to 
the  STARS  Repository  System  causing  adverse  impact  to  repository  users. 
Additional  description  of  the  repository  system  hardware  is  in  "Reposi¬ 
tory  System  Software"  on  page  35. 


3.3  REPOSITORY  ASSESSMENT 


The  assessments  contained  in  the  following  paragraphs  are  based  on  a 
manual  examination  of  a  large  number  of  the  current  components  and  the 
use  of  the  Repository  System  to  develop  STARS  contract  deliverables.  The 
current  operating  procedures  were  also  reviewed  with  respect  to  the  manual 
steps  required  and  the  results  achieved.  The  primary  conclusions  are  that 
the  current  repository  capabilities  are  powerful  with  respect  to  search 
and  access  but  that  additional  tools  or  automation  is  required  to  effi¬ 
ciently  install  components  in  the  repository. 

A  more  automated  process  to  load  components  and  information  that  describe 
components  will  reduce  labor  costs  and  increase  the  quality  of  the  data. 
The  first  step  in  this  direction  was  in  the  gatekeeper  (CDRL  1570)  and 
provides  a  general  capability  to  "filter"  components  that  are  supplied 
to  the  repository.  The  prototype  allows  insertion  of  new  automated  tools 
into  the  filtering  and  acceptance  process.  Suppliers  can  also  execute  the 
process  or  portions  of  the  process  to  assure  themselves  of  the  correctness 
of  submissions  before  the  Repository  Staff  become  involved  resulting  in 
fewer  rejects  (and  reduced  labor  costs  for  repository  operation). 


3.3.1  REPOSITORY  SYSTEM  CAPABILITIES 


The  capabilities  provided  by  the  Repository  System  were  used  to  develop 
the  latest  capabilities  added  to  the  repository  prototype.  This  included 
Ada  programming  support  (i.e.,  APSE)  and  database  application  development 
support  (i.e.,  Oracle  RDBMS  support  tools).  Other  general  capabilities 
were  used  including  MAIL  and  FORUM  communication  as  well  as  repository 
contents  and  capabilities,  e.g.,  a  new  version  of  the  Window  Manager, 
Problem  Reports,  and  help/ information  scored  on  the  Repository  System. 

The  capabilities  of  the  system  were  adequate  to  evolve  the  repository 
prototype  and  to  support  the  repository  in  a  software  development  envi- 
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ronment.  Component  search  and  access  was  acceptable  at  2400  baud  but 
limited  productivity  in  a  real  development  effort,  e.g.,  CDRL  1600.  The 
transfer  rate  was  also  too  slow  to  distribute  large  components  or  a  large 
number  of  components.  The  9600  rate  was  acceptable  for  the  development 
efforts  and  most  data  transfers  (9600  was  very  unreliable  because  of 
frequent  errors  and  dial-up  line  disconnects).  The  STARS  Repository 
should  support  bulk  data  transfers  via  magnetic  tape  or  diskettes  to 
achieve  significant  usage  by  development  projects. 


3.3.2  REPOSITORY  CAPABILITIES 


The  capabilities  of  the  repository  would  have  been  more  responsive  to  the 
reuser  if  the  repository  and  repository  capabilities  were  installed  lo¬ 
cally  and  shadows  of  the  libraries  moved  periodically  by  bulk  transfer 
(CDRL  0470).  The  repository  capabilities  allow  documents  and  component 
analysis  reports  to  be  located  and  reused.  This  does  save  significant 
development  time  over  manual  directory  search  and  retrieval.  All  docu¬ 
ments  and  Ada  code  deliverables  should  be  moved  to  the  repository  library 
to  allow  for  faster  searching,  i.e.,  efficient  reuse  of  the  information. 


3.3.3  CONTENTS 


The  contents  of  the  repository  need  be  increased  to  include  many  more 
ready-to-use  components,  e.g.,  large  components  that  have  already  been 
tested  and  integrated  with  other  reusable  components.  Productivity  does 
not  significantly  increase  by  the  use  of  a  few  small  reusable  components, 
e.g.,  stacks,  queues,  and  lists.  The  large  and  high  quality  components 
(e.g.,  dictionaries,  window  managers,  navigation,  guidance,  and  control 
packages)  provide  significantly  better  gains  in  productivity. 

All  types  and  sizes  (i.e.,  domain  and  scope)  of  reusable  information  and 
software  code  (i.e.,  Ada  and  non-Ada  programming/sourcc)  are  supported. 
The  emphasis  should  be  placed  on  collecting  large,  high  quality  software. 
High  quality  includes  components  that  are  easy  to  use,  well  documented, 
tested,  and  enhanced,  i.e.,  contain  test  data,  analysis  reports,  and  in¬ 
tegrated.  Integrated  components  include  those  that  are  built  to  the  same 
set  of  standards,  virtual  interfaces  or  abstract  layers,  and  have  been 
tested  with  other  components  that  are  contained  in  the  repository.  Com¬ 
pleteness,  correctness,  and  consistency  of  the  information  in  the  repos¬ 
itory  are  required  attributes  for  any  repository  to  achieve  wide-spread 
acceptance.  The  following  policies  and  procedures  are  the  first  items 
recommended  for  achieving  the  desired  repository  attributes. 


3.3.4  DATA  RIGHTS 


The  current  contents  include  many  components  where  the  data  rights  are 
not  clearly  described.  The  current  contents  should  be  updated  and  all 
new  component  submissions  checked  for  conformance  with  the  guidelines  and 
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4.0  POLICIES  AND  PROCEDURES 


The  following  paragraphs  contain  the  initial  set  of  recommended  policies 
and  procedures  organized  by  the  role  of  the  corresponding  user.  The  first 
set  presented  are  applicable  to  any  user,  the  remaining  paragraphs  are 
grouped  by: 

•  Component  Supplier/Owner 

•  Repository  System  Manager 

•  Repository  System  Administrator 

•  Repository  Administrator/Librarian 

•  Component  Reuser/Subscriber 


4.1  GENERAL  POLICIES  AND  PROCEDURES 


The  recommended  policies  and  procedures  for  the  STARS  Repository  System 
are  listed  in  the  following  paragraphs.  These  policies  and  procedures 
shall  be  updated  as  the  mission  or  scope  of  the  repository  changes. 


4.1.1  POLICIES 


The  repository  manager  is  expected  to  maintain  a  set  of  repository  poli¬ 
cies  and  have  procedures  in  place  to  ensure  that  each  policy  is  appro¬ 
priate  during  the  operational  lifetime  of  the  STARS  repository. 

1.  The  initial  availability  of  the  STARS  Repository  will  be  for  access 
by  any  individual  or  organization  participating  in  U.S.  Government 
sponsored  programs.  After  the  repository  capabilities  have  stabi¬ 
lized  and  contents  have  expanded  (i.e.,  the  STARS  Program  has  deter¬ 
mined  that  the  contents  have  proven  themselves  to  the  point  that  users 
can  expect  to  achieve  a  significant  cost  savings)  the  scope  of  users 
can  be  extended  (e.g.,  to  academic  and  commercial  organizations). 

2.  Users  of  the  repository  shall  be  currently  registered  individuals 
associated  with  a  particular  registered  organization.  This  require¬ 
ment  can  be  satisfied  by  simple  registration  forms  to  be  completed 
and  signed  and  filed  with  the  Repository  staff.  Each  organization 
shall  be  responsible  for  the  accuracy  of  the  registration  information 
of  both  the  organization  and  the  individuals  registered  in  associ¬ 
ation  with  that  organization. 

3.  Organizations  shall  register  and  identify  an  individual  to  assist  the 
Repository  Manager  with  the  administration  of  the  repository,  e.g., 
the  identification  of  valid,  registered  members  of  the  organization, 
the  assignment  or  the  recovery  from  lost  passwords.  The  identified 
individual  will  receive  periodic  repository  status  information  and 
repository  activity  or  other  summary  reports  associated  with  the  or¬ 
ganization. 
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4.  The  definition  of  (STARS  Repository  System)  registered  organizations 
is  not  limited  to  a  company,  division  of  a  company,  a  specific  site, 
or  any  Government  agency  partitioning  but  each  organization  shall 
designate  a  specific  individual  (i.e.,  to  coordinate  repository  re¬ 
lated  activities)  and  the  organization  must  have  a  valid  mailing  ad¬ 
dress.  A  network  mailing  address  for  on-line  transfer  is  desirable 
but  shall  not  be  required. 

5.  Information  relating  to  individuals  or  organizations  that  is  not  re¬ 
quired  for  legal  or  a  specific  operational  requirement  identified  in 
the  STARS  Operational  Procedures  shall  not  be  stored  in  the  Repository 
System.  Information  that  is  stored  shall  only  be  distributed  as  de¬ 
fined  the  operational  procedures  or  by  a  specific  court  order. 

6.  All  information  stored  about  an  individual  or  organization  shall  be 
readily  available  to  the  corresponding  individual  or  organization. 
Such  information  will  be  purged  when  it  is  no  longer  required.  De¬ 
letion  of  the  information  can  occur  at  the  termination  of  a  valid 
registration  status  as  defined  in  the  operational  procedures. 

7.  No  DoD  Classified  information  and  ITAR  (International  Traffic  in  Arms 
Regulations)  items  will  be  stored  in  the  repository  until  such  time 
as  adequate  content  protection  mechanisms  are  in  place  as  well  as 
methods  to  identify  authorized  individuals.  The  protection  mechanism 
includes  the  distribution  process  to  the  requesting  individual  or 
organization. 

8.  Proprietary  or  other  company  labelled  confidential  information  shall 
not  be  stored  in  the  STARS  Repository. 

9.  Copyrighted  information  (or  other  forms  of  protection)  by  individuals 
or  organizations  can  be  stored  in  the  repository  if  the  appropriate 
authority  has  been  acquired  to  store,  duplicate,  distribute,  and  use 
the  information. 

10.  Information  with  other  forms  of  protection  (e.g.,  Patent)  can  be 
stored  as  long  as  the  terms  and  conditions  allow  the  Government  and 
Government  contractors  to  use  and  maintain  (e.g.,  Government  purpose 
license)  the  component.  The  complete  definition  of  all  maintenance 
restrictions  shall  be  included,  e.g.,  only  corrections  to  existing 
capabilities . 

11.  Operational  staff  shall  not  discuss  or  report  specific  information 
relating  to  the  rejection  of  submitted  components  or  parts  to  anyone 
other  than  the  corresponding  supplier  or  their  representative. 

12.  Operational  staff  shall  not  retain  data  from  submitted  components  or 
component  parts  if  the  submission  is  rejected  and  not  corrected  by 
the  supplier  beyond  30  days  unless  previously  agreed  to  by  the  sup¬ 
plier  and  repository  manager. 

13.  The  collection  or  growth  of  the  repository  contents  will  be  driven 
by  the  availability  of  reliable,  reusable  components.  The  effort  ex¬ 
pended  in  growth  will  be  based  on  a  priority  established  by  the  STARS 
Program,  e.g.,  the  frequency  of  occurrence  of  particular  functions 
in  current  or  future  DoD  Contracts  and  the  degree  to  which  candidates 
match  standards  established  for  the  STARS  Program.  This 
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prioritization  will  take  into  consideration  current  trends  in  stand¬ 
ardization  that  are  occurring  in  the  industry. 

14.  Priority  'shall  be  given  to  Government  owned  information  and  public 
domain  information  over  more  restricted  types,  e.g.,  joint  ownership. 
Guidelines  and  procedures  shall  be  included  in  the  STARS  Operational 
procedures  to  assist  in  the  validation  of  data  rights  associated  with 
the  information  contained  in  the  repository. 

15.  Duplicate  or  overlapping  component  capabilities  will  be  allowed  but 
efforts  should  be  expended  to  ensure  implementations  are  available 
for  a  set  of  platforms  as  determined  by  the  STARS,  Program.  The 
platform  does  include  both  development  environments  (host  systems) 
and  the  application  environments  (target  systems).  The  definition  of 
environment  includes  hardware  (e.g.,  a  particular  commercial  system) 
and  software  (e.g.,  one  or  more  components  such  as  operation  system 
and  database  system) . 

16.  Information  contained  in  Problem,  Response,  and  Change  Reports  shall 
not  contain  confidential  or  proprietary  data  as  defined  above.  The 
information  shall  be  available  to  any  individual  having  access  to  the 
corresponding  Component  or  Repository  System  capability,  e.g.,  the 
information  shall  be  available  for  use  by  the  individual  having  re¬ 
trieved  or  subscribed  to  the  Component  with  the  understanding  that 
the  report  is  the  opinion  of  the  author  and  has  not  been  reviewed  for 
correctness  or  applicability  to  the  particular  user's  particular  ap¬ 
plication. 

17.  Any  and  all  fees  charged  to  registered  individuals  or  organizations 
must  be  clearly  defined  in  the  STARS  Operational  Procedures  and  ap¬ 
proved  by  the  STARS  Program  or  the  responsible  organization  within 
the  DoD. 

18.  Repository  staff  shall  ensure  the  acceptance  criteria  and  procedures 
do  not  impose  an  unjustified  burden  on  a  particular  supplier  or  class 
of  suppliers.  This  includes  making  sure  the  filtering  process  is 
simple,  documented,  and  fair  to  all  suppliers. 


4.1.2  STANDARDS  OF  CONDUCT 


Every  user  of  the  STARS  Repository  System  is  expected  to: 

1.  Adhere  to  the  policies  and  procedures  that  are  defined  to  ensure  the 
Repository  System  can  be  of  maximum  benefit  to  the  user  community. 

2.  Adhere  to  the  STARS  Repository  System  warning  and  advisory  messages 
appearing  at  the  time  of  sign-on  or  during  the  user's  terminal  ses¬ 
sion. 

3.  Adhere  to  the  data  rights  and  other  restrictive  clauses  contained  in 
the  accessed  or  retrieved  information,  i.e.,  the  reusable  Components 
and  Component  Parts. 
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4.  Report  all  known  problems  with  security,  integrity,  or  service  to  the 
Repository  System  Manager  and  to  his/her  organization's  designated 
coordinator  and  other  appropriate  authority. 

5.  Treat  and  support  users  or  user  classes  the  same,  without  regard  to 
the  individual,  their  organization,  or  the  project  with  which  they 
are  associated  with  unless  approved  by  the  STARS  Program  or  respon¬ 
sible  DoD  organization.  This  statement  does  not  apply  in  the  case 
of  restricted  data  rights  or  for  any  other  legal  restrictions  or 
considerations . 

6.  Submit  no  information  to  the  repository  that  is  know  to  be  incorrect, 
e.g.,  components,  parts,  and  reports.  Likewise,  no  user  shall  gen¬ 
erate  Problems  Reports  that  are  known  to  be  incorrect  or  mislead  any 
other  user. 

7.  Define  passwords  at  least  6  (six)  characters  in  length  and  not  triv¬ 
ial,  e.g.,  a  common  name,  initials,  date,  or  any  obvious  value  or 
pattern  that  could  be  easily  associated  with  a  repository  function 
or  an  individual. 

8.  Redefine  your  password  at  least  every  sixty  days  or  when  notified  by 
the  Repository  System  Administrator. 

9.  Report  lost  or  compromised  passwords  to  the  Repository  System  Manager 
and  to  your  organization's  designated  coordinator  or  other  appropri¬ 
ate  authority  (if  you  suspect  compromised  or  destroyed  data). 


4.1.3  COMMUNICATION  PRIVACY 


Recorded  information  that  relates  to  specific  individuals,  e.g.,  computer 
time  used  and  component  subscriptions,  shall  only  be  communicated  with 
the  corresponding  user,  the  organization's  designated  user  (or  alternate) 
for  repository  coordination,  the  System  Manager,  and  anyone  designated 
in  the  contractual  documents  related  to  the  repository  operation.  The 
System  Administrator  shall  use  the  designated  user  (or  alternate)  to  as¬ 
sist  in  the  recovery  from  a  forgotten  password  to  confirm  the  identity 
of  the  user. 


4.1.4  PROCEDURES 


The  following  procedures  are  applicable  to  any  user  of  the  repository, 
i.e.,  suppliers,  operations  staff,  and  reusers.  Specific  procedures  for 
each  major  type  of  user  is  included  in  subsequent  paragraphs. 


Policies  and  Procedures 


15 


4. 1.4.1  Registration 


All  STARS  Repository  Users  shall  provide  the  information  required  to  op¬ 
erate  the  repository  in  an  efficient  and  safe  manner,  i.e.,  to  ensure  that 
data  integrity,  security,  and  access  policies  of  the  STARS  Repository 
System  can  be  enforced.  This  information  includes  data  on  the  user 
(Figure  4  on  page  44)  and  the  user's  organization  (  Figure  6  on  page 
45) . 


4. 1.4. 2  Security 


All  users  are  responsible  for  security  on  a  day-to-day  basis,  e.g.,  not 
sharing  or  otherwise  exposing  passwords.  The  Repository  System  manager 
is  responsible  for  ensuring  proper  definition  of  and  adherence  to  security 
procedures,  e.g.,  initiating  unannounced  audits.  The  Repository  System 
Administrator  can  be  assigned  the  task  of  the  actual  audit  or  it  can  be 
assigned  to  an  outside  organization.  Detailed  procedures  are  discussed 
in  paragraphs  that  correspond  to  the  various  Repository  Staff  roles. 


4. 1.4. 3  Termination 


The  organization  or  the  organization's  designated  coordinator  shall  be 
responsible  for  notifying  the  Repository  System  manager  or  the  System 
Administrator  when  user  registrations  are  to  be  terminated,  e.g.,  the 
particular  user  is  no  longer  a  member  of  the  organization.  Termination 
of  the  user's  registration  or  specific  library  access  rights  can  be  ini¬ 
tiated  by  the  System  Manager  for  serious  violations  of  the  repository 
policies . 


4. 1.4. 4  Data  Rights 


All  users  (i.e.,  suppliers,  repository  staff,  and  reusers)  are  to  respect 
the  individual  data  rights  of  individuals  or  organizations.  The  staff 
shall  be  responsible  for  ensuring  that: 

•  All  submitted  components  contain  clear,  standard  statements  of  ap¬ 
propriate  data  rights  information,  e.g.,  "Certificate  of  Origin"  on 
page  40. 

•  All  users  are  made  aware  of  limited  rights  information  that  may  reside 
on  the  repository,  e.g.,  on-line  user  information  that  inform  all 
users  of  the  standard  locations  where  terms  and  conditions  (or  re¬ 
strictions  and  releases)  are  documented,  e.g.,  "Component  Terms  and 
Conditions  Form"  on  page  41. 

•  All  distributed  components  that  require  special  labels  that  describe 
ownership  and  restrictions  are  so  identified  in  the  repository  and 
on  distrilutions  of  the  component  to  reusers,  e.g.,  "Distribution 
Labels"  on  page  43. 
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All  users  are  made  aware  that  they  should  notify  the  STARS  Repository 
System  manager  if  they  recognize  or  believe  incorrect  data  rights 
information  is  stored  in  the  repository  (or  in  items  distributed  from 
the  repository) . 


4.2  SUPPLIERS 


The  following  policies  and  procedures  apply  to  anyone  that  submits  com¬ 
ponents  or  other  information  to  the  repository,  i.e.,  new  or  revised 
components  and  information  relating  to  repository  components. 


4.2.1  POLICY 


1.  All  suppliers  and  potential  suppliers  wishing  to  participate  in  the 
STARS  Repository  program  shall  be  registered  as  defined  in  the  General 
Policies  stated  above. 

2.  Any  supplier  wishing  to  remain  active  shall  adhere  to  the  established 
policies  and  procedures  established  for  the  STARS  Repository. 

3.  Supplier,  owner,  or  contributor  shall  submit  information  with  com¬ 
plete  documentation  of  data  rights,  i.e.,  document  complete  ownership 
and  include  appropriate  joint  ownership  releases  (as  defined  in  the 
STARS  Operational  Procedures). 

4.  Do  not  submit  any  information  that  is  known  to  have  or  require  a  DoD 
security  classification  other  than  "UNCLASSIFIED". 

5.  Do  not  submit  any  information  that  is  or  should  be  ITAR  controlled 
unless  the  procedures  defined  in  the  STARS  Operational  Procedures  are 
followed. 

6.  All  information  required  for  submitted  components  shall  be  supplied 
complete  and  in  the  form  or  forms  specified  in  the  STARS  Operational 
Procedures.  This  includes  content,  media,  and  formats  processable 
by  the  available  STARS  Repository  hardware  and  software  systems. 

7.  Decisions  on  Component  Qualification  or  Disqualification  are  to  be 
made  by  the  STARS  Repository  Manager,  but  appeals  for  review  can  be 
made  to  the  STARS  Program  Manager  or  responsible  organization  within 
the  DoD.  Likewise,  Component  Migration  and  Retention  is  as  defined 
in  the  STARS  Operational  Procedures,  and  all  conflict  resolution  de¬ 
cisions  are  made  by  the  STARS  Repository  Manager.  This  includes  de¬ 
cisions  on  the  contents  of  any  user  supplied  comments  or  reports. 
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4.2.2  PROCEDURES 


Suppliers  should  include  all  information  they  consider  reusable  with  the 
components  submitted.  This  should  include  all  information  that  is  re¬ 
quired  (as  described  in  CDRL  items  1460,  1550,  and  1570).  The  components 
submitted  should  also  meet  some  stated  objective  or  need.  The  components 
should  require  minimum  re-work  on  the  part  of  the  reusers.  If  the  sub¬ 
mitted  components  use  or  require  component  versions  that  already  exist 
in  the  repository,  do  not  re-submit  the  duplicate  versions  of  shared 
components.  Also,  duplicate  component  part  versions  (i.e.,  shared  compo¬ 
nent  parts)  should  not  be  transmitted  or  shipped.  If  the  removal  of  du¬ 
plicate  versions  of  parts  is  not  practical,  then  at  least  identify  reused 
parts  in  new  or  revised  component  submissions. 

Components,  component  revisions,  and  other  communication  related  to  sub¬ 
mitted  components  shall  be  in  a  format  and  medium  that  is  supported  by 
the  STARS  Repository  System. 


4.2.2. 1  New  Components 


Suppliers  should  attempt  to  evaluate  and  test  submitted  components  using 
the  same  tools  and  following  the  same  procedure:,  as  the  repository  li¬ 
brarian  to  increase  the  probability  of  the  components  being  accepted. 
Otherwise,  additional  communication  and/or  rework  will  increase  overhead 
cost  for  the  component  supply  and  repository  operation  process.  Data  that 
is  required  with  every  new  component  include  component  identification 
data  (Figure  1  on  page  39)  and  information  describing  the  data  rights  of 
the  component  ("Certificate  of  Origin"  on  page  40). 


4. 2. 2. 2  Revised  Components 


Revisions  and  variations  of  existing  components  can  be  submitted  to  the 
repository  by  the  original  supplier  or  by  reusers  of  the  components,  i.e., 
if  permitted  from  a  legal  or  data  rights  standpoint  (CDRL  1460) .  A  Change 
Report  should  always  be  submitted  with  a  revised  component  to  provide 
summary  information  for  the  existing  subscribers  or  reusers  as  well  as 
potential  users.  This  report  should  list  all  Problem  Reports  that  are 
addressed  in  the  revision  and  any  changes  to  existing  limitations  or  ca¬ 
pabilities  that  might  be  significant  to  reusers,  i.e.,  information  that 
might  help  users  on  decisions  to  move  to  a  newer  version  of  a  component 
or  that  might  help  other  users  with  an  initial  selection  of  a  component 
version  (or  variation) . 

Always  provide  updated  identification  data  (Figure  1  on  page  39)  when 
revisions  to  existing  components  are  submitted.  If  applicable,  also  in¬ 
clude  revised  data  rights  information.  Revised  components  are  tested 
and/or  evaluated  as  a  complete  entity,  as  if  the  component  ware  a  new 
submission.  Previous  versions  of  revised  components  will  be  retained 
on-line  or  archived  by  the  librarian,  according  to  current  policies  of 
the  repository.  Users  that  are  currently  subscribed  to  the  component  will 
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also  be  notified  as  appropriate;  therefore,  the  supplier  should  not  change 
the  name  of  ah  existing  component  when  a  revision  is  made. 

Major  changes  to  the  capability  or  function  of  an  existing  component  can 
imply  a  new  name  if  the  two  component  versions  are  to  coexist  for  an  ex¬ 
tended  period  of  time.  Duplicate  component  names  can  also  be  handled  by 
unique  component  numbers  associated  with  components  stored  in  the  repos¬ 
itory.  Suppliers  should  assist  the  librarian  so  decisions  have  the  min¬ 
imum  impact  on  current  or  potential  reusers.  In  general,  if  earlier 
versions  of  parts  and/or  components  are  useful  from  a  reuse  standpoint; 
therefore,  retain  existing  previous  versions  of  components  or  parts  in 
such  a  manner  that  continued  maintenance  and  selection  can  occur  in  the 
presence  of  new  derived  parts  or  components.  When  user  selection  of 
previous  versions  or  variations  stopped  then  the  librarian  will  archive 
or  delete  the  earlier  versions  or  variations. 


4. 2. 2. 3  Component  Promotion 


The  promotion  of  components  to  higher  repository  levels,  e.g.,  certified, 
is  a  process  accomplished  by  the  librarian,  but  the  supplier  can  improve 
or  speed-up  the  process  by  making  sure  the  required  information  and  any 
optional  information  is  provided,  e.g.,  comprehensive  test  procedures, 
test  case/driver  logic,  and  test  data  are  available. 


4.3  REPOSITORY  MANAGER 


The  Repository  Manager  will  ensure  that  repository  policies,  guidelines, 
standards,  and  procedures  are  adequate  and  monitored  when  appropriate. 
The  policies  and  procedures  established  for  the  STARS  Repository  should 
be  maintained  and  accessible  on-line  by  any  user.  This  is  desirable  for 
either  a  Public  access  or  limited  access  repository.  Grouping  of  user 
information  should  be  by  user  role,  e.g.,  Repository  Suppliers,  Managers, 
and  Re-users.  The  Repository  Manager's  responsibilities  include  the 
following: 

•  Operation  of  the  STARS  Repository  System 

•  Adherence  to  Laws,  Regulations,  and  Directives 

•  Fairness  in  the  operation  of  the  repository 

•  Standards  and  Usability  of  the  repository 

•  Detection  of  Restricted  and  Proprietary  Data 

•  Security  and  Auditing  of  the  Repository 

•  Contract  specified  Cost  and  Fee  considerations 


4.3.1  POLICIES 

1.  Do  not  accept  or  store  information  that  is  marked  (or  you  have  reason 
to  believe  is)  proprietary.  Company  Confidential,  or  DoD  Confidential 
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(or  higher) .  Return  such  information  to  the  supplier  and  notify  the 
STARS  Project  or  DoD  organization  responsible  for  the  repository. 

2.  Do  not  accept,  store,  of  allow  access  to  information  that  is  marked 
(or  you  have  reason  to  believe  should  be  handled)  as  requiring  special 
control  for  access  and  distribution,  e.g.,  ITAR,  until  such  time  as 
an  adequate  protection  is  provided  by  the  Repository  System. 

3.  Ensure  that  STARS  Repository  Procedures  and  adequate  protection  exist 
for  information  (other  than  Government  owned  wTith  unlimited  distrib¬ 
ution  and  Public  Domain)  before  such  information  is  available  for  user 
access.  A  defined  set  of  independent  audits  of  the  procedures,  fa¬ 
cilities,  and  repository  operations  shall  occur  before  a  new  re¬ 
stricted  access  class  is  supported.  The  procedures  should  establish 
routine  and/or  random  audits  for  some  restricted  access  classes, 
e.g.,  ITAR  controlled  items. 

4.  Priorities  shall  be  established  and  approved  by  the  STARS  Program  or 
DoD  organization  responsible  for  the  repository  before  soliciting  new 
components  from  suppliers.  Likewise,  filtering  procedures  and 
acceptance/rejection  criteria  should  be  baselined,  made  available 
on-line  for  current  users,  and  distributed  to  potential  suppliers 
(and  included  with  any  solicitation  for  components). 

5.  All  laws,  regulations,  and  directives  must  be  obeyed.  Report  any  known 
inconsistencies  to  the  STARS  Program  or  responsible  organization. 
Document  all  procedures  used  to  ensure  compliance  with  laws,  regu¬ 
lations,  and  directives. 


4.3.2  COMMUNICATION 


The  Repository  Manager  shall  periodically  report  the  status  of  the  STARS 
Repository  System  and  a  summary  of  the  component  reuse/subscription  data 
as  defined  in  the  repository  operations  contract.  This  information  will 
be  distributed  as  specif’ ?.d  in  the  contract,  but  no  data  will  be  included 
in  the  reports  that  identify  specific  users,  to  allow  maximum  availability 
of  the  reports  to  interested  parties. 


4.3.3  PROCEDURES 


The  contractor  managing  the  Repository  System  will  face  some  risk,  e.g., 
real  or  a  perceived  bias  (or  unfair  advantage)  with  respect  to  operating 
the  STARS  Repository  System,  The  bias  or  risk  can  be  overcome  somewhat 
by  the  independent  selection  of  hardware,  software,  and  interfaces,  i.e., 
industry  standards  selected  to  build  or  to  grow  the  Repository  System. 
An  impact  to  the  contractor  could  be  the  possible  exclusion  from  specific 
procurements,  e.g.,  selecting  or  developing  specific  reusable  components. 

A  competitive  advantage  could  be  gained  if  the  contractor  managing  the 
repository  gained  a  significant  experience  with  the  contents  and  the 
capabilities  of  the  repository  to  better  compete  for  related  software 
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development.  This  could  become  very,  significant  if  the  contractor  was 
to  treat  one  registered  user  organization  different  from  others.  This 
possibility  implies  that  at  least  a  code  of  conduct  is  required  on  the 
operation  of  the  repository.  Other  users  may  need  to  be  guided  by  this 
code  of  conduct  since  there  may  be  cases  where  the  action  of  one  user 
could  possible  affect  another  user. 

In  addition,  procedures  used  in  the  operation  of  the  repository  and  the 
control  of  repository  capabilities  should  be  periodically  reviewed  to 
ensure  their  current  validity  and  fairness  to  the  current  and  potential 
users  of  the  repository.  The  following  paragraphs  define  an  initial  set 
of  procedures  for  the  operation  of  the  repository. 


4.3.3. 1  User  Interface 


The  initial  sign-on  response  and  high-level  menus  should  allow  any  user 
to  locate  general  information  about  the  repository.  This  information 
should  define  the  scope,  use,  and  ownership  of  the  information  contained 
in  the  repository  and  should  also  be  a  cookbook  on  how  to  use  the  various 
features  of  the  repository  as  well  as  the  reusable  contents.  It  should 
also  state  that  Problem  Reports  and  Problem  Report  Responses  generated 
by  users  of  the  repository  can  be  used  by  other  users  of  the  repository 
without  restriction.  It  should  clearly  point  out  that  the  reports  are 
to  be  interpreted  in  a  specific  context,  e.g.,  they  are  not  necessarily 
the  belief  of  the  original  author  or  current  owner  of  the  Component. 

Likewise,  the  Repository  System  Problem  Reports  are  not  necessarily  the 
opinions  of  the  Repository  Manager  or  operations  personnel.  The  responses 
to  System  Problems  should  be  approved  by  the  Repository  Manager,  and  the 
Component  Problem  Response  should  be  approved  by  the  Component  Owner  be¬ 
fore  the  Problem  Report  is  considered  closed.  All  information  contained 
within  a  Component  or  Component  Part  (Variation  or  Version)  should  be 
considered  a  part  of  that  component  and  not  changed  unless  a  new  Variation 
or  Version  is  created.  The  purpose  of  this  dual  strategy  (i.e.,  dynamic 
reports  and  static  component  contents)  is  to  increase  the  confidence  of 
potential  users  and  hot  require  individual  users  to  track  changes  and 
change  rationale.  This  should  be  accomplished  through  the  Component  or 
Component  Part  Change  Reports,  and  therefore  the  users  can  get  the  in¬ 
formation  to  select  particular  repository  entries,  i.e,  initial  se¬ 
lections  or  subsequent  replacement  of  a  previously  selected  items. 


4. 3. 3. 2  Laws,  Regulations,  and  Directives 


It  is  very  important  to  establish  an  evolving  STARS  Operational  Procedure 
to  provide  day  to  day  guidance  to  all  organizations  and  individuals  since 
laws,  regulations,  and  directives  will  continue  to  change.  Likewise,  the 
interpretation  of  these  items  are  will  evolve  based  on  court  decisions 
and  the  understanding  that  individuals  have  of  the  terminology  and  the 
evolving  reuse  technology.  In  particular,  the  Repository  System  must  have 
procedures  that  are  easily  understood  and  carried  out  by  the  users,  i.e., 
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Repository  Suppliers  ,  Repository  Managers,  and  the  Re-users..  In  partic¬ 
ular,  the  procedures  should  address  and  reference  the  following  items: 

•  Freedom  of  Information  Act 

•  Privacy  Act 

•  Federal  Records  Act 

•  Export  Control  Laws 

•  Regulations  and  Directives 

Explicit  policies  and  procedures  can  avoid  significant  problems  with  the 
above  items  by  preventing  needless  retention  of  information,  by  limiting 
access  to  the  information  that  must  be  retained,  and  by  securing  only  that 
information  that  can  not  be  made  available  to  all  users.  Components 
covered  by  Export  Control  Laws  and  International  Traffic  in  Arms  Regu¬ 
lations  (ITAR)  can  be  satisfied  without  a  major  effort  by  using  the  Data 
and  Analysis  Center  for  Software  (DACS)  as  a  model. 


4. 3. 3. 3  Standards  and  Usability 


The  selection  of  the  set  of  standards  to  be  supported  in  a  repository  as 
well  as  the  repository  capabilities  can  affect  one  contractor  to  a  greater 
extent  than  it  would  another  contractor.  This  includes  such  items  as 
access  to  interconnected  networks  and  the  interface  standards  used  for 
remote  dial-up  terminals.  The  publishing  of  catalogues  and  other  indexes 
used  to  select  components  off-line  could  assist  in  this  area.  The  se¬ 
lection  of  standards  or  changes  that  affect  usability  of  the  repository 
should  be  approved  by  the  STARS  Program  or  the  responsible  organization 
within  the  DoD. 


4. 3. 3. 4  Restricted  and  Proprietary  Data 


If  restricted  or  proprietary  data  is  stored  in  the  repository,  then  the 
contractor  managing  or  supporting  the  operation  of  the  repository  could 
be  exposed  to  additional  risks  related  to  intellectual  property  or  trade 
secrets.  This  could  involve  nondisclosure  agreements  with  the  owners  of 
the  material.  It  could  also  require  the  individuals  supporting  operation 
of  the  repository  to  be  restricted  from  specific  activities  during  the 
support  period  or  for  a  period  of  time  after  such  support. 


4. 3. 3. 5  Security  and  Auditing 


The  complexity  and  magnitude  of  the  STARS  Repository  System,  including 
the  hardware,  software,  and  operating  procedures,  are  such  that  security 
and  other  types  of  audits  should  be  done  on  a  regular  basis.  Reports 
generated  by  the  audits  should  be  forwarded  to  the  STARS  Program  or  the 
responsible  organization  within  the  DoD. 
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4. 3. 3. 6  Cost  and  Fee  Procedures 


The  charging  of  user  fees  or  the  collecting  or  billing  of  royalties  for 
Government  or  commercially  owned  items  is  beyond  scope  of  this  report. 
It  should  be  noted  that  other  repositories  do  charge  users  for  specific 
requested  items,  e.g.,  DACS  and  NASA’s  COSMIC  repository  (CDRL  1450). 
Additional  capabilities  would  be  required  in  the  STARS  Repository  System 
and  the  Operating  Procedures  to  charge  users,  e.g.  a  fee  for  distribution 
of  the  Components  or  Component  Parts  selected  by  a  user. 


4.4  REPOSITORY  SYSTEM  ADMINISTRATOR 


The  following  paragraphs  describe  the  system  administrator  role  and  the 
polices  and  procedures  that  relate  directly  to  that  role.  This  may  be 
one  individual  or  multiple  individuals  with  specific  skills  and  respon¬ 
sibilities,  e.g.,  database  administrator  (BDA) .  Specific  individual  as¬ 
signments  related  to  the  STARS  Repository  System,  e.g.,  installing  new 
products,  are  assumed  to  be  an  administrator's  task. 


4.4.1  REPOSITORY  SYSTEM  PROCEDURES 


The  administrator  of  the  repository  system  is  responsible  for  the  proper 
day-to-day  operation  of  the  system  including  both  the  hardware  ("Hard¬ 
ware"  on  page  8)  and  the  software  ("Software"  on  page  9).  The  adminis¬ 
trator  shall  maintain  a  set  of  detailed  operating  procedures  and  records 
that  would  allow  reassignment  of  specific  tasks  and  support  auditing  of 
the  repository  system  operation.  The  current  prototype  repository  system 
has  provided  an  opportunity  to  study  and  document  practical  aspects  of 
the  repository  operation  (CDRL  1440). 

The  administrator  shall  also  update  the  portion  of  the  evolution  plan  that 
relates  to  the  system  hardware  and  software  in  the  following  areas: 

•  Security  of  physical  and  intellectual  property 

•  Integrity  of  the  system  capability  and  data 

•  Capacity  planning  and  capacity  management 

•  Response  time  and  availability  of  the  system 

•  User  command  menus,  information,  and  support 


4. 4. 1.1  Security 


The  administrator  shall  ensure  the  security  of  physical  and  intellectual 
assets  by  planning  and  accomplishing  the  following  items: 

•  Physically  secure  the  computer  equipment 

•  Meet  or  exceed  electrical  and  fire  codes 

•  Escort  all  visitors  in  the  computer  room 
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•  Use  access  control  on  all  computer  fi-les 

•  Track  and  periodically  audit  all  assets 

•  Maintain  current  set  of  authorized  users 

•  Keep  correct  address/distribution  lists 

•  Require  and  monitor  the  use  of  passwords 

•  Remind  users  of  their  responsibilities 

•  Report  known/possible  security  breaches 

•  Conduct/have  independent  security  audits 

Many  of  the  above  items  require  continuous  execution;  others  require  ex¬ 
ecution  as  the  need  arises  or  periodic  accomplishment,  e.g.,  audits  of 
all  assets  and  reminding  the  users  of  their  responsibilities.  Detail 
procedures  shall  be  defined  to  describe  the  methods  used  and  frequency. 


4. 4. 1.2  Integrity 


The  administrator  shall  ensure  the  integrity  of  the  repository  system  and 
repository  contents  by  planning  and  accomplishing  the  following  items: 

•  Backup  repository  system  data  off-site 

•  Test  all  new/updated  products  off-line 

•  Check  imported  software  for  viruses,  etc. 

•  Specify  data  checking  (equipment/modes) 

•  Provide  and  test  backup/recovery  process 

The  administrator  shall  work  directly  with  the  repository  librarian  to 
ensure  that  the  integrity  requirements/approach  are  complete  and  effi¬ 
cient  for  the  repository  capabilities,  the  repository  data,  and  the  re¬ 
pository  users'  data. 


4. 4. 1.3  Capacity,  availability,  and  response  time 


The  administrator  shall  ensure  adequate  data  processing,  storage,  and 
communication  is  available  for  the  repository  system  and  repository  con¬ 
tents  by  planning  and  accomplishing  the  following  items: 

•  Ensure  adequate  buffer  for  static  and  peak  load 

•  Select  products  that  monitor  performance 

•  Periodically  monitor/report  system  load 

•  Tune  the  processing/database  capability 

•  Repair  or  replacement  of  failed  equipment 

The  above  items  should  be  worked  on  with  the  repository  librarian,  but 
stay  within  the  resources  available  to  the’  repository  manager.  The  re¬ 
sources  expenditure  should  be  balanced  to  provide  maximum  repository 
utility  but  be  consistent  with  the  evolution  plan  and  repository  operation 
contract. 
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4. 4. 1.4  User  Support 


The  administrator  has  the  primary  responsibility  to  provide  support  to 
the  repository  system  users  by  providing  the  following  services: 

•  Provide  on-line  and  off-line  user  assistance 

•  Installing  on-line  product  help  or  information 

•  Ensuring  that  information  is  concise  and  clear 

•  Bulk  distribution  of  information  to  new  users 

•  Answer/refer  repository  system  problem  reports 


4.4.2  REPORT  PROCESSING 


The  administrator  shall  monitor  the  problem  reports  generated  against 
each  product  and  ensure  that  the  vendors  or  other  responsible  individuals 
receive  the  reports  and  that  appropriate  closure  and/or  reassignment  is 
accomplished.  Invalid  or  outdated  reports  should  be  removed  from  the 
system.  Repository  system  menus,  general  information,  and  specific  in¬ 
formation  should  be  maintained  to  reflect  the  current  status  of  the  cur¬ 
rently  supported  products  or  tools.  Status  should  include  significant 
items  contained  in  problem  report  responses.  A  brief  summary  of  the 
significant  user  reported  items  and  major  new  or  updated  capabilities 
should  be  announced  or  referenced  on  the  system  sign-on  screen. 

The  administrator  should  always  send  a  message  to  the  originator  of  a 
problem  report  to  provide  immediate  feedback  on  a  possible  work-around 
and  to  thank  the  individual  for  the  effort  to  report  the  problem.  The 
originator  should  also  receive  a  message  when  the  problem  report  is  or 
will  be  closed  at  a  later  date.  In  general,  encourage  users  to  generate 
problem  reports  and  to  provide  candidate  alternatives  to  other  users. 


4.5  REPOSITORY  LIBRARIAN 


The  following  paragraphs  describe  the  repository  librarian  role  and  the 
polices  and  procedures  that  relate  directly  to  that  role.  The  librarian 
may  be  one  individual  or  multiple  individuals  with  specific  skills  and 
responsibilities,  e.g.,  domain  or  topic  specialist  and  reuse  experts. 
Specific  individual  assignments  related  to  the  repository  contents,  e.g., 
evaluation  of  a  submitted  component,  are  presented  as  librarian  tasks. 
The  actual  tasks  may  be  performed  by  an  individual  performing  more  than 
a  conventional  librarian's  role,  e.g.,  component  problem  tracking  and 
maintenance,  and  the  expanded  role  could  be  called  the  "repositarian". 


4.5.1  REPOSITORY  PROCEDURES 


The  primary  task  for  the  librarian  is  to  receive  candidate  components  from 
suppliers  or  other  sources  of  reusable  components  or  information.  Can- 
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didate  components  are  to  be  processed  quickly  and  in  a  efficient  manner 
but  caution  should  always  be  exercised  since  minor  problems  that  go  un¬ 
detected  can  result  in  significant  loss  of  time  and  resources  (by  multiple 
reusers  that- review  or  select  a  defective  component).  The  librarian  should 
acknowledge  receipt  of  candidate  components  to  the  supplier  as  soon  as 
they  are  received  and  provide  an  estimate  of  the  time  it  will  take  to 
process  the  components  and  install  or  add  them  to  the  repository.  Notify 
the  supplier  if  this  estimate  changes  by  more  than  one  week. 

Return  all  supplied  items,  e.g.,  components,  to  the  submitter  if  one  or 
more  repository  policies  are  violated,  e.g.,  inclusion  of  proprietary 
items  without  prior  agreement  between  the  repository  manager  and  the 
supplier.  Also  notify  the  repository  manager  of  all  items  rejected  or 
returned  to  the  supplier  along  with  the  rationale  for  the  action. 


4. 5. 1.1  Checking  and  Updating  Database  Information 


The  librarian  shall  ensure  the  supplier  is  either  currently  registered 

or  the  appropriate  forms  are  attached  or  can  be  filled  out  and  added  to 

the  repository  database.  The  librarian  shall: 

•  Add  required  information  to  the  database  for  all  first-time  suppliers 
(Figure  4  on  page  44)  and  for  all  unique  organizations  (Figure  6  on 
page  45). 

•  Add  component  information  (Figure  1  on  page  39)  after  the  component 
is  processed  and  accepted. 

•  Add  contract  information  (Figure  7  on  page  46)  if  the  candidate  com¬ 
ponent  was  developed  or  updated  under  a  specific  Government  contract. 

•  Update  existing  database  information  when  provided  on  new  or  updated 
forms,  but  duplicate  information  will  not  be  stored,  e.g.,  user,  or¬ 
ganization,  or  contract  descriptions. 

•  Test  new  registrations  entries  and  all  updates  to  user  or  organization 
data  by  using  the  information  for  sending  a  response  to  the  supplier 
and/or  organization's  designated  coordinator. 


4. 5. 1.2  Checking  Data  Rights  Information 


Check  all  owner-related  information,  e.g.,  a  Certificate  of  Origin  that 
describes  "data  rights"  history  of  a  software  component.  If  the  component 
submitted  to  the  repository  is  a  complete  system,  subsystem,  or  other 
major  unit  that  has  one  or  more  reusable  sub-units  then  the  entire  set 
must  be  assumed  to  have  the  same  disclaimer  and  release  of  data  rights. 
A  set  of  the  certificates  for  such  a  Component  would  be  very  desirable. 
Otherwise,  individual  selectable  sub-units- would  have  to  have  this  data 
documented  in  the  individual  sub-unit  prologues  (CDRL  1460) . 

The  only  reason  for  any  sub-unit  granularity  is  based  of  the  advantage 
of  being  able  to  break-up  major  delivery  items  into  lower-level  reusable 
information  or  software.  The  minimum  information  required  is  included  in 
Figure  2  on  page  40,  and  the  form  should  identify  and  be  signed  by  the 
both  the  Contracting  Officer  and  the  Contractor  or  their  representatives. 
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Notify  the  supplier  immediately  of  any  missing  or  invalid  information 
immediately,  e.g.,  release  of  data  rights  by  the  author  or  owner. 


4. 5. 1.3  Checking  Basic  Qualifications 


Process  all  submitted  components  to  ensure  that  the  basic  requirements 
and  other  criteria  have  been  meet  as  described  in  the  STARS  Repository 
Guidebook  (CDRL  1540) .  This  includes  all  restrictions  on  media  and  format 
of  the  submitted  material  as  well  as  required  and  recommended  information 
content  including: 

•  Component  description  and  abstract 

•  Supplier  and  taxonomic  information 

•  Owner  and  distribution  limitations 

•  Component  testing/using  instructions 

Notify  the  supplier  immediately  if  required  information  is  missing  or  if 
invalid  data  is  present  that  would  prevent  further  processing  or  potential 
selection  by  users.  If  a  component  fails  to  meet  the  minimum  acceptance 
criteria  (e.g.,  for  entry  into  a  depository  level  library),  the  librarian 
shall  retain  the  submitted  items  for  a  period  of  30  days  (or  longer  if 
approved  by  the  submitter  and  repository  manager)  to  allow  the  supplier 
to  submit  additional  items  or  to  replace  parts. 


4. 5. 1.4  Checking  Quality  and  Completeness 


Each  component  submitted  will  be  processed  to  ensure  the  minimum  quality 
level  for  admission  to  the  repository.  Additional  checks  (within  the 
available  repository  resources,  i.e.,  tools,  computer  capacity,  and  labor 
hours)  will  be  made  to  minimize  the  impact  to  reusers.  A  prototype  (CDRL 
1570)  of  an  automated  process  is  available  for  the  initial  operation  of 
the  repository.  The  librarian  should  recommend  additional  tools  or 
changes  to  the  prototype  to  increase  productivity,  e.g.,  reduce  cost  by 
using  an  automatic  analysis  tool.  Additional  details  of  the  manual  and 
automated  filtering  processes  are  described  in  the  following  paragraphs. 
Additional  details  on  the  processes  should  be  documented  and  maintained 
in  future  updates  of  these  repository  procedures  and  will  including  the 
following  types  of  checks: 

•  compilation  of  Ada  language  parts 

•  build/link  and  execute  test  cases 

•  gather  standard  metrics  on  parts 

•  run  text  processor  on  SGML  parts 

•  print  or  process  Postscript  parts 

•  display  and  review  all  ASCII  text 

•  identify  portability  limitations 

•  identify  usability  characteristics 

•  identify  interface/design  standards 
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4. 5. 1.5  Component  Loading 


A  candidate  component  can  be  added  to  the  depository  (e.g.j  only  supplier 
data  is  checked)  or  to  the  filter  repository  after  the  component  has  met 
the  minimum  acceptance  criteria  (CDRL  1540) .  Loading  can  be  delayed  if 
the  supplier  agrees  to  make  corrections  that  would  significantly  enhance 
the  quality  or  the  portability  and  usability  characteristics  of  the  com¬ 
ponent.  Summaries,  i.e.,  metrics  or  other  analysis  data,  should  be  for¬ 
matted  for  quick  examination  by  potential  reusers  and  included  as  a 
component  part.  All  parts  should  be  moved  to  a  repository  library,  i.e., 
make  accessible  to  the  repository  users. 

The  repository  level  at  which  the  component  is  stored  (e.g.,  depository, 
organized,  or  filtered)  depends  on  the  level  the  component  was  able  to 
achieve  in  the  filtering  process.  Any  highest  level,  e.g.,  certified, 
requires  additional  independent  testing  and  evaluation.  The  necessary 
levels  and  detailed  processes  to  achieve  the  different  levels  is  still 
to  be  determined  through  protot3rpe  experience  and  after  justification  of 
the  cost,  i.e.,  additional  tools  and  repository  capabilities. 


4.5.2  DETAIL  FILTERING  PROCEDURES 


All  software  components  should  contain  a  prologue  as  defined  in  the  STARS 
Repository  Operating  Procedures  (CDRL  1460)  or  contain  the  same  type  of 
information  in  an  acceptable  form  provided  by  the  supplier.  Other  reus¬ 
able  information  submitted  (e.g.,  documents)  should  contain  similar  data 
rights  information  and  should  be  imbedded  in  each  component  in  an  ac¬ 
ceptable  format  and  transfer  medium,  i.e.,  in  an  electronic  form  accept¬ 
able  for  automatic  processing  by  the  STARS  Repository  supply  tools  or 
filtering  process. 

The  following  is  a  list  of  the  prologue  contents  appearing  in  software 
from  the  Ada  Software  Repository  (SIMTEL20)  and  may  be  used  as  a  model. 
The  original  Terms  and  Conditions  are  usually  not  included  in  the  unit. 
The  releases  contained  in  the  SIMTEL20  and  other  repositories  typically 
require  that  the  prologue  be  copied  along  with  the  duplicated  software, 
updated  versions,  or  derivative  work  products. 

•  Header  statements  that  identify  the  basic  attributes  of  the  unit 

•  Copyright  statement  and  basic  overview  information  about  the  unit 

•  Distribution  and  copyright  limitations  and/or  release  statements 

•  Disclaimer  statements  intended  to  relieve  the  author  of  liability 

•  Terms  and  conditions  imposed  by  contracts  associated  with  the  unit 

•  Restrictions  imposed  on  this  unit  by  laws/regulations  or  contracts 

The  term  unit  is  used  since  one  or  more  units  may  be  stored  in  a  single 
software  program  or  distribution  file.  Programming  languages,  such  as 
Ada,  allow  software  specifications  to  be  in  a  separate  unit  from  the  im¬ 
plementation,  and  they  may  have  different  owners  and  different  clauses 
included  relating  to  data  rights.  A  similar  situation  can  occur  for  other 
forms  of  information,  e.g.,  the  parts  or  chapters  of  a  document. 
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4.5,2. 1  Header  Statements 


The  purpose- of  the  header  of  the  prologue  is  to  quickly  identify  the  unit 
by  name,  version,  and  key  individuals  associated  with  the  component  part. 
In  practice,  some  of  the  fields  may  have  to  be  maintained  by  the  Reposi¬ 
tory  System,  e.g.,  contact  names  and  addresses.  Other  fields,  e.g., 
versions,  may  have  to  be  mapped  to  versions  numbers  maintained  in  the 
Repository  System  if  derivative  units  are  created. 


4. 5. 2. 2  Release  Statements 


The  purpose  of  the  Release  portion  of  the  prologue  is  to  document  the 
formal  release  or  transfer  of  data  rights  for  the  unit.  This  should  cover 
reproduction,  distribution,  modification,  or  the  generation  of  derived 
work  products  unless  the  release  removes  all  existing  data  rights  of  the 
author,  all  joint  developers,  and  all  subsequent  owners  of  the  unit.  For 
Government  or  Government  contracted  software  development  this  information 
may  be  copied  from  the  Terms  and  Conditions  related  to  the  implementation. 


4. 5. 2. 3  Disclaimer  Statements 


The  purpose  of  the  disclaimer  statement  is  to  warn  potential  users  that 
the  unit  may  or  may  not  be  free  of  errors  or  be  suited  to  the  user's  ap¬ 
plication  or  environment.  Such  statements  are  usually  worded  in  such 
manner  that  would  avoid  or  limit  the  liability  of  the  author.  These 
statements  may  or  may  not  be  adequate  in  particular  cases  or  in  specific 
court  jurisdictions. 


4. 5. 2. 4  Restriction  Statements 


This  portion  of  the  prologue  may  not  apply  to  all  software  and  may  be 
omitted  or  indicated  as  "NONE"  in  the  comment  field.  This  section  should 
include  or  reference  information  related  to  Defense  Acquisition  Regu¬ 
lations  (DAR)  and/or  explicit  contract  Terms  and  Conditions  that  the 
software  was  developed.  This  should  include  all  items  that  relate  to  data 
rights,  ownership,  or  other  limitations  that  has  been  placed  on  the  unit. 
Suppliers  (developers  or  the  owners).  Reusers,  and  the  STARS  Repository 
Managers  should  be  aware  that  contracts  can  be  modified  during  the  de¬ 
velopment  phase  or  sub-contracts  issued  for  the  actual  implementation; 
therefore  this  section  should  reflect  the  final  set  of  Terms  and  Condi¬ 
tions  or  other  legal  restrictions  that  apply  to  the  unit  delivered  to  the 
repository.  If  export  control  laws  apply,  then  the  restrictions  must  be 
included  in  these  statements. 
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4. 5. 2, 5  Terms  and  Conditions 


Terms  and  Conditions  may  have  to  be  signed  before  requests  for  specific 
items  in  the  repository  can  be  made,  i.e.,  an  approved  request  form  must 
be  processed  before  the  requested  items  can  be  distributed  to  the  user. 
If  the  repository  is  expanded  to  distribute  components  where  further 
distribution  or  incorporation  into  commercial  products  is  not  allowed, 
then  procedures  must  be  defined  to  must  be  control  and  track  explicit 
requests  for  the  component,  e.g.,  software  code  and/or  documentation. 

Specific  items  on  the  form  in 'Figure  3  on  page  41  can  be  omitted,  e.g., 
if  export  control  is  not  involved.  The  remaining  two  items  that  are  in 
the  DACS  request  forms  involve  the  possibility  of  receiving  classified, 
proprietary,  or  export  controlled  items  and  need  not  be  included  if  such 
material  is  not  to  be  stored  in  the  STARS  Repository  System;  otherwise, 
ensure  all  the  items  listed  in  the  form  are  included. 

The  completed  form  (or  expanded  form)  shall  identify  and  be  signed  by  both 
the  requestor  and  the  approving  authority  or  their  representatives.  The 
identification  of  individuals  signing  the  request  shall  include  their 
complete  title,  name,  and  address  as  well  as  the  complete  name  and  address 
of  their  respective  organizations.  This  form  shall  also  include  the  STARS 
Repository  System  number  assigned  to  the  requesting  individual  as  well 
as  an  approved  Contractor  Number,  e.g.,  as  assigned  by  the  Defense  Lo¬ 
gistics  Services  Center  (DLSC).  The  sample  user  registration  (Figure  4 
on  page  44)  and  organization  (  Figure  6  on  page  45)  are  similar  to  the 
DACS  registration  forms  currently  being  used  except  for  the  header  and 
item  one  (1)  and  the  substitution  of  the  work  "software"  for  "package" 
to  simplify  the  terminology  (note:  software  is  defined  as  reusable  com¬ 
ponents  including  documentation  in  item  1.). 


4. 5. 2. 6  Other  Acceptance  Criteria 


Other  criteria  are  described  in  the  Repository  Guidebook  (CDRL  1540)  and 
the  process  is  included  in  the  repository  Filter  Prototype  (CDRL  1570). 
If  the  minimum  acceptance  criteria  are  met  then  the  repository  loading 
process  can  be  initiated.  If  the  minimum  criteria  is  not  met  then  the 
supplier  shall  be  contacted  and  notified  of  the  discrepancies.  No  further 
action  should  be  taken  until  the  minimum  acceptance  criteria  is  met. 


4.5.3  DETAIL  LOADING  PROCEDURES 


The  sample  forms  in  the  appendix  contain  information  that  may  also  appear 
in  a  prologue  of  a  component  submitted  to  the  repository.  It  may  not 
feasible,  however,  for  some  types  of  components  to  have  a  prologue,  e.g., 
a  large  set  of  information  fragments.  It  is  also  likely  that  information 
being  transferred  from  some  other  repository  en  masse  will  not  have  pro¬ 
logues.  The  librarian  should  use  the  information  provided  in  the  prologue 
(or  found  during  the  filtering  process)  to  classify  the  component.  The 
prologue  type  information  can  be  stored  as  a  shared  component  part  for 
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those  components  where  it  is  not  feasible  to  include  a  prologue  with  each 
individual  prologue.  The  information  will  be  used  (in  either  case)  to 
initialize  the  database  tables  that  are  required  to  support  component 
search  and  access  (CDRL  1600). 


4.5.3. 1  Facets  and  Facet  Terms 


The  currently  defined  facets  and  terms  supported  by  the  repository  should 
be  matched  against  the  characteristics  or  attributes  of  the  component  and 
the  database  tables  set  to  allow  selection  of  the  component  by  users  that 
are  searching  for  one  or  more  of  these  characteristics.  The  librarian 
should  also  maintain  a  list  of  the  attributes  that  do  not  match  the  cur¬ 
rent  facets,  facet  terms,  and  aliases  of  terms.  This  list  should  be  ex¬ 
amined  periodically  with  the  a  history  of  the  currently  used  facets  and 
terms  to  determine  when  the  repository  capability  should  be  updated. 


4. 5. 3. 2  Attributes 


The  repository  supports  a  set  of  attributes  that  have  not  been  defined 
in  the  faceted  classification  scheme,  e.g.,  author.  Some  of  these  at¬ 
tributes  could  become  facets  if  the  repository  prototype  experience  jus¬ 
tifies  such  a  change,  e.g.,  the  set  of  authors  could  be  predefined  and 
one  or  more  picked  for  a  search  operation.  Until  that  occurs,  the  data¬ 
base  has  to  be  updated  to  connect  the  attribute  value  to  the  component 
and  the  user  has  to  be  prompted  to  enter  a  specific  attribute  value  (in¬ 
cluding  possible  wild-cards  supported  by  the  database  system). 


4. 5. 3. 3  hierarchical  classification 


The  librarian  should  attempt  to  classify  each  component  with  the  existing 
taxonomy  or  classification  index  used  by  the  prototype  repository.  This 
is  useful  for  storing  and  searching  for  contract  deliverables  are  already 
in  a  task  break-down  order.  Users  can  then  search  and  browse  CDRL  items 
in  the  groupings  they  were  contracted  and  delivered  without  knowing  the 
specific  attributes.  A  list  of  the  problems  encountered  in  hierarchical 
classification  of  the  components  should  be  maintained  for  possible  future 
modifications  to  the  classifications.  Periodically  review  the  list  of 
problems  along  with  user  comments  to  determine  when  a  change  should  be 
made. 


4. 5. 3. 4  Keyword  Search  Support 


The  current  prototype  repository  should  be  modified  to  support  a  keyword 
search  scheme.  The  supply  and  the  filter  processes  should  be  modified 
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to  check  for  keywords  in  the  component  prologue.  These  words  can  also 
assist  the  librarian  in  the  classification  of  the  component. 


4.5.4  DETAIL  DISTRIBUTION  PROCEDURES 


When  hard-copy  or  off-line  bulk  distribution  is  supported,  these  proce¬ 
dures  have  to  be  updated  to  include  the  management  of  duplication  services 
and  control  over  consumables,  e.g.,  tapes,  diskettes,  and  printer  paper. 
At  this  time  all  distribution  is  assumed  to  be  in  electronic  form  and  to 
be  initiated  and  controlled  by  the  repository  user,  e.g.,  individual  file 
transfer  using  Kermit  or  any  other  method. 


4.5.5  REPOSITORY  ARCHIVE/PURGE  PROCEDURES 


A  detail  set  of  procedures  should  be  developed  and  maintained  to  ensure 
the  repository  resources  are  not  burdened  by  outdated  or  unused  versions 
or  variations  of  components.  The  initial  procedure  could  be  to  delete 
all  previous  versions  of  components  60  days  after  user  retrievals  have 
stopped  for  the  particular  version  or  variation.  Current  subscribers 
should  be  notified  that  a  new  version  or  variation  is  available  and  that 
the  usage  of  old  versions  will  determine  when  an  archive/purge  is  to  oc¬ 
cur.  The  advantage  of  retaining  older  version  is  to  provide  users  with 
selection  options  that  they  can  select  after  reviewing  change  and  problem 
reports  of  the  current  on-line  versions. 


4. 5. a  REPORT  PROCESSING 


The  librarian  should  monitor  the  problem  reports  generated  against  the 
components  and  ensure  that  the  supplier  or  other  responsible  individual 
receives  the  report  and  that  appropriate  closure  and/or  reassignment  is 
accomplished.  Invalid  or  outdated  reports  should  be  removed  from  the 
repository.  Change  reports  should  also  be  reviewed  to  ensure  that  the 
information  is  concise,  correct,  and  contains  references  to  other  infor¬ 
mation,  e.g.,  problem  reports  written  against  earlier  versions  of  the 
component . 

The  librarian  should  regenerate  the  on-line  catalog  anytime  a  major  set 
of  components  is  added  to  the  repository.  The  current  subscribers  to  a 
component  should  be  sent  a  message  when  a  new  version  of  that  component 
is  added.  These  subscribers  should  also  be  sent  a  message  when  a  major 
problem  is  detected  or  is  closed  for  that  component,  e.g.,  a  work-around 
to  a  major  problem  is  defined. 
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4.6  COMPONENT  REUSER/SUBSCRIBER  ■ 


The  repository  component  reuser  or  any  user  subscribing  to  components 
within  the  repository  shall  adhere  to  all  repository  polices  relating  to 
the  use  of  the  repository  and  repository  components.  This  includes  com¬ 
plete  and  correct  registration  information,  updating  of  passwords,  and 
reporting  of  security  violations.  The  most  current  general  user  infor¬ 
mation  and  messages  from  the  operations  staff  should  be  examined  imme¬ 
diately  before  accessing  the  repository  contents  or  before  using 
repository  services,  e.g.,  the  Ada  compiler.  Detailed  user  requirements 
and  procedures  are  documented  in  text  files  available  after  sign-on. 
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APPENDIX  A.  REPOSITORY  SYSTEM  DESCRIPTION 


The  following  description  of  the  hardware  and  software  contained  in  the 
repository  system  is  not  intended  to  complete  but  is  included  to  provide 
an  overview  the  repository  operation.  This  overview  is  intended  to  help 
define  the  knowledge  and/or  skills  required  of  the  operations  staff. 


A.  1  REPOSITORY  SYSTEM  HARDWARE 


The  following  hardware  descriptions  represent  typical  elements  that  can 
be  used  to  implement  a  specific  instance  of  a  repository  system. 


A.  1.1  PROCESSORS 


The  computer  for  the  STARS  Repository,  e.g.,  a  central  repository  for  the 
STARS  Program,  shall  be  a  commercially  available  processor  selected  to 
meet  the  documented  standards  and  performance  requirements.  Peak  proc¬ 
essing  requirements  are  determined  by  the  system  capabilities  made 
available  to  the  user  and  the  magnitude  of  the  individual  processing  re¬ 
quests,  e.g.,  database  searches,  compilation  of  source,  and  execution  of 
test  cases  to  evaluate  selected  components.  The  computer  system  shall  have 
the  capability  to  support  many  concurrent  users  and  to  support  assigning 
priority  to  component  search,  access,  and  distribution. 


A.  1.2  STORAGE 


The  on-line  storage  capability  shall  be  sufficient  to  support  the  user's 
data  requirements  and  the  response  time  constraints  for  the  repository 
system.  The  user  data  requirements  include  the  user  registration  data 
and  user's  own  local  storage  required  by  the  repository  services,  e.g., 
execution  of  component  analysis  tools  and  the  Ada  compiler.  Off-line 
storage  shall  be  provided  for  backup  of  the  repository  system  and  for 
archiving  seldom  used  or  previous  versions  of  repository  components,  re¬ 
pository  system  capabilities,  and  computer  system  products. 

Archives  shall  be  used  to  provide  additional  backup  for  system  failures. 
Standard  magnetic  tapes,  diskettes,  and  other  media  shall  be  available 
for  backups,  for  archives,  and  for  bulk  distribution.  The  hardware  in¬ 
cludes  both  the  storage  device  and  associated  computer  system  interface 
devices.  Both  electronic  and  hard-copy  information,  e.g.,  duplicates  of 
user  registration  forms,  shall  be  maintained  off-site  from  the  STARS  Re¬ 
pository  to  protect  against  the  total  destruction  of  data. 
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A. 1.3  COMMUNICATION 


User  communication  hardware  includes  computer  console  terminals,  remote 
user  terminals,  modems,  rotary  dial-up  connection  units,  local  and  remote 
networks,  and  interface  devices  required  for  the  computer  and  network 
connections.  The  numbers  of  devices  and  data  rates  supported  shall  be 
documented  in  the  repository  system  evolution  plan  along  with  the  network 
protocols  and  device  interface  standards.  A  summary  of  the  current  ca¬ 
pabilities  and  standards  shall  be  available  on-line  and  documented  in  the 
Repository  Guidebook. 


A.  1.4  NETWORKS  AND  TERMINALS 


One  or  more  terminals  are  required  to  operate  and  maintain  the  STARS  Re¬ 
pository  System.  The  set  of  terminals  types  used  by  the  operational  staff 
shall  be  a  good  cross-section  of  the  wide  set  of  terminals  that  are  ex¬ 
pected  to  be  used  by  the  suppliers  and  reusers.  This  also  includes  the 
"Terminal/Network  Support"  on  page  36  designed  to  emulate  standard  ter¬ 
minal  types  or  network  protocols.  As  the  STARS  Repository  System  evolves, 
the  range  of  terminals  may  include  powerful  workstations  designed  to 
support  the  various  phases  of  the  software-first  life  cycle,  e.g.,  pre¬ 
liminary  design  or  prototype.  One  or  more  networks  could  be  installed 
for  development,  porting,  and  testing  of  components,  e.g.,  Ethernet. 


A. 1.5  PERIPHERALS 


In  addition  to  the  storage  devices,  additional  peripherals  shall  be 
available  to  produce  or  duplicate  hard-copy  (e.g.,  printed  reports)  and 
electronic  or  optical  media  required  for  bulk  distribution.  This  includes 
the  production  of  hard-copy  catalogs,  reports,  and  mailing  labels.  It 
also  includes  tapes,  diskettes,  and  other  media  for  bulk  distribution, 
e.g.,  to  sites  not  connected  by  high-speed  data  links. 


A. 2  REPOSITORY  SYSTEM  SOFTWARE 


The  following  software  descriptions  represent  typical  products  that  can 
be  used  to  implement  a  specific  instance  of  a  repository  system. 


A. 2.1  GENERAL  SUPPORT 


The  primary  software  required  by  the  repository  system  is  the  Operating 
System  (OS).  The  OS  manages  the  resources  of  the  computer  system  and 
provides  services  to  the  operations  staff  and  to  the  repository  system 
user.  The  OS  and  associated  commercial  support  products  shall  be  selected 
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to  be  compatible  with  the  "Hardware"  on  page  8  and  the  STARS  Repository 
System.  Other  general  software  requirements  can  be  satisfied  by  the  com¬ 
mercial  Operating  System  or  by  separate  licensed  or  purchased  products 
including: 

•  Configuration  Management  System 

•  Performance/Response  Measurement 

•  Resource  Utilization  Measurement 

•  User  Accounting/Billing  System 

•  Communication  by  mail  and  forum 


A. 2. 2  TERMINAL/NETWORK  SUPPORT 


Commercial  or  Government  developed  software  is  required  to  support  the 
minimum  set  of  terminals  and  networks  directly  involved  with  the  STARS 
Repository  System.  Additional  combinations  of  equivalent  products  could 
provide  additional  repository  services,  i.e.,  capabilities  for  problem 
analysis  in  direct  support  of  registered  users,  porting  and  testing  of 
repository  components,  and  improving  the  usability,  capability,  and  scope 
of  the  STARS  Repository  System.  Examples  of  products  and/or  component 
testing  environments  are: 

•  Ethernet  and  Token-Ring  Networks  (and  bridges) 

•  Dial-up/Modems,  e.g. ,  1200,  2400,  and  9600 

•  Terminal  OS  or  emulators,  e.g., 

-  DEC  VT100  and  VT220  (trademarks  of  Digital  Equipment  Corporation) 
IBM  PC  RT  and  PS/2  (trademarks  of  the  IBM  Corporation) 

•  Terminal  emulators,  e.g., 

-  IBM  File  Transfer  and  Terminal  Emulator  Program  (FTTERM) 

-  Persoft  Smarterm  220  (trademark  of  Persoft  Corporation) 

-  ProComm  (trademark  of  Datastorm  Technologies  Corporation) 

•  File  Transfer  methods,  e.g., 

-  FTP  (File  Transfer  Protocol,  see  note  below) 

-  KERMIT 

-  XM0DEM/YM0DEM 

•  Distributed  process/data  methods,  e.g., 

-  RPC  (Remote  Procedure  Call,  see  note  below) 

-  Distributed  and/or  Network  Server  databases 

Note:  Compatible  Terminal  Control  Program/Internet  Protocol  (TCP/IP)  and 
network/bridge  software  is  required  for  FTP  or  RPC  support. 


A. 2. 3  TEXT  AND  GRAPHICS  SUPPORT 


The  current  support  in  the  STARS  Repository  System  is  limited  to  ASCII 
character  text  documents  and  to  Postscript.  The  documents  can  include 
imbedded  figures  and  examples  that  are  simple  graphics  containing  only 
valid  characters  represented  as  allowed  by  the  Standard  Generalized 
Markup  Language  (SGML).  Some  of  these  capabilities  are  available  (e.g., 
postscript  generation),  or  various  prototypes  are  in  existence.  The 
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long-term  requirements  for  text  and  graphic  support  products  or  tools 
include: 

•  Text  and  graphic  editors 

•  Text  and  graphic  formatters 

•  Simple  character/line  diagrams 

•  Libraries  of  graphic  symbols 

•  Complex  2-D  and  3-D  Diagrams 

•  Display  and  printing  support 


A. 2. 4  PROGRAMMING  SUPPORT 


The  minimum  requirement  is  for  an  integrated  Ada  Programming  Support  En¬ 
vironment  (APSE)  that  can  be  used  to  evolve  and  maintain  the  STARS  Re¬ 
pository  System.  This  includes  a  compiler,  linker,  debugger,  and  a 
complete  Ada  Run  Time  Environment  (ARTE).  The  APSE,  including  the  ARTE, 
shall  also  be  used  to  support  the  development  and  maintenance  of  the  re¬ 
pository  contents.  Additional  hardware  and/or  software  may  be  required 
to  support  the  porting  and  testing  of  the  reusable  components  on  other 
host  or  target  platforms,  e.g.,  a  different  vendor's  hardware  and  opera¬ 
tion  system.  The  responsibility  for  porting  and  testing  on  other  plat¬ 
forms  can  be  assigned  to  the  component  supplier  or  be  covered  by  separate 
contracts,  different  contractors  and  contractor  sites.  The  STARS  Reposi¬ 
tory  System  can  be  used  to  store  and  distribute  components  that  are  de¬ 
veloped  and  verified  to  execute  on  different  platforms. 

Assembler  language  support  is  required  in  the  APSE  for  each  platform  to 
develop  and  maintain  interfaces  to  the  hardware  and  software  products, 
e.g.,  Virtual  Operating  System  Interface  (VOSI),  Ada/SQL  Bindings,  and 
Graphical  Device  Interfaces  (GDI).  Depending  on  the  particular  binding 
to  commercial  standards  or  interfaces  to  specific  commercial  products, 
other  language  and  VOSI  support  tools  may  also  be  required,  e.g.,  data 
conversion  from  one  standard  to  another  commercial  standard..  Initially 
a  commercial  relational  data  base  management  system  (RDBMS)  is  being  used, 
but  as  the  STARS  Program  evolves  the  database  could  be  migrated  to  a 
comprehensive  object  oriented  data  base  management  system  (OODBMS). 

In  addition  to  the  minimum  APSE  requirement,  the  following  capabilities, 
products,  or  tools  shall  be  integrated  with  the  STARS  Repository  System. 

•  Language  Sensitive  Editor  for  Ada 

•  Ada  source-code/static  analysis  tools 

•  Ada  object -code/run-time  analysis  tools 

•  Assembler/Assembly  Language  support  tools 

•  Ada/SQL  Bindings  to  the  commercial  RDBMS 

•  Graphic  System  Bindings/Interface,  e.g.,  GKS 


Appendix  A.  Repository  System  Description 


37 


A. 2. 5  DATABASE  SUPPORT 


The  database  support  requirements  includes  both  a  sequential  file  storage 
hierarchy  and  relational  table  storage  (RDBMS).  Specific  requirements 
include: 

•  Table,  sequential  file,  and  file  directory  backup  and  recovery 

•  Transaction  level  or  multiple  access  data  table/file  protection 

•  Access  security  including  creation,  updating,  and  read-only 

•  Performance  measurements  and  accounting  or  usage  monitoring 

•  Report  generation,  mail  or  print  formatting,  and  distribution 

The  commercial  OS  that  is  currently  used  by  the  STARS  Repository  System 
provides  most  of  the  required  services.  The  commercial  RDBMS  used  by  the 
STARS  Repository  System  provides  several  of  the  other  required  services. 


A. 2. 6  PERIPHERAL  SUPPORT 


The  specific  support  software  depends  on  the  specific  hardware  and  soft¬ 
ware  products  used  in  the  STARS  Repository  Syste,..  and  network  access  to 
repository  users  but  in  general  includes  the  following  items: 

•  Report  or  text  output  spooling  and  line  printer  control 

•  User  file  collection  and  distribution,  e.g.,  magnetic  tape 

•  Repository  report  generation  and  distribution,  e.g.,  changes 

•  Component  report  generation  and  distribution,  e.g.,  catalog 

The  commercial  Operating  System  (OS)  that  is  currently  used  by  the  STARS 
Repository  System  and  in  the  prototype  capabilities  (CDRL  1600)  provide 
most  of  the  required  services. 
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APPENDIX  B.  REPOSITORY  SYSTEM  FORMS 


B.  1  COMPONENT  REGISTRATION  FORM 

The  first  form.  Figure  1,  contains  data  that  will  vary  depending  upon  the 
type  of  component  being  submitted.  This  form  is  to  be  expanded  or  altered 
for  new  repository  scope  or  requirements. 

STARS  REPOSITORY  SYSTEM 
Component  Registration  Form 

.  'ie :  __ 

Version: 

Access  Type: 

Author  ID: 

Attributes:  (Required  unless  supplied  in  the  Component  Prologue) 

Type:  _ SOFTWARE _  Class:  _ 

Medium:  _  Size:  _ 

Structure:  _  Format:  _ 

Concurrency: 

Media  Mgmt . : 

Contact:  _ 

User  Identification  Name:  _ 

Organization  Identification  Number:  _ 

- Completed  by  Repositcr  -  System - 

Repository  Entrance  Date:  _ 

New  Component  Identification  Number:  _ 

Notes:  Attach  Certificate  of  Origin  Forms  to  all  new  components 
and  revised/duplicate  forms  to  new  versions  of  components. 

Attach  Change  Reports  for  all  new  versions  of  registered 
components/component  parts  (by  Name  and  Version  Number). 

Figure  1.  Example  of  Component  Registration  Form 


Bounded: 
Iter at ion: 


Old  Component  ID: 

_ _  Contract  ID: 

Owner  ID: 
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B.2  CERTIFICATE  OF  ORIGIN 


The  data  supplied  in  the  certificate  is  similar  to  data  a  Contracting 
Officer  might  request  from  the  contractor  based  on  statements  contained 
in  the  Request  for  Proposals,  e.g.,  "the  offerer  agrees  to  furnish  clear 
and  convincing  evidence  that  the  data  which  will  be  so  identified  comes 
within  the  definition  of  limited  rights  data."  The  actual  providers  of 
all  or  portions  of  the  software  may  be  the  subcontractors  of  the  con¬ 
tractor. 


STARS  REPOSITORY  SYSTEM 
Certificate  of  Origin  Form 


Identification 
Contract  Name: 

Contract  Number: 

Unit  Name: 

Unit  Version: 

Copyright  Information 
Copyright  Owner: 

Date  of  First  Issue: 
Date  of  Last  Revision: 
Owner (s)  of  Unit 
Name  of  Owner: 

Owner's  Address: 

Item  Description: 

Imported  Elements: 

Restrictions 

Security  Restrictions: 

Privacy  Restrictions: 

Export  Restrictions: 

Market  Restrictions: 


(full  name  of  the  development/buy  contact) 
(Government  contract  number  if  applicable) 
(full  name  of  the  software  unit  described) 
(full  identification,  release  number,  etc.) 
(required  or  specified  NO  COPYRIGHT  exists) 
(full  name  of  individual  or  company  owner) 
(Copyright  date,  not  contract/delivery  date) 
(required  or  stated  as  NO  EXISTING  REVISION) 
(repeat  the  following  items  for  each  owner) 
(full  name  of  individual  or  company  owner) 
(complete  current  address  of  above  owner) 

(use  required  number  of  lines) 

(Brief  description  of  developed/bought  items) 
(use  required  number  of  lines) 

(Brief  description,  source  of  Non-U. S.  items) 
(use  required  number  of  lines) 

(Brief  description,  reason  for  restriction) 
(use  required  number  of  lines) 

(Brief  description,  reason  for  restriction) 
(use  required  number  of  lines) 

(Brief  description,  reason  for  restriction) 
(use  required  number  of  lines) 

(Brief  description,  reason  for  restriction) 
(use  required  number  of  lines) 


Figure  2.  Sample  Certificate  of  Origin  Form 
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B.3  COMPONENT  TERMS  AND  CONDITIONS  FORM 


The  next  form,  Figure  3,  documents  the  terms  and  conditions  reuser  must 
agree  to  before  specific  restricted  libraries  may  be  accessed  or  the 
corresponding  components  are  retrieved,  e.g.,  ITAR,  Government  programs 
only,  and  DoD  programs  only. 

STARS  REPOSITORY  SYSTEM 
Component  Terms  and  Conditions  Form 

(1)  Release  of  the  following  Repository  component (s)  is  requested: 
(repeat  the  following  line  as  required) 

Name :  Number : 


(2a)  Requested  component/s  will  be  used  on  the  following  contract(s): 
(repeat  the  following  line  as  required) 

Contract  Name  Number : 


(2b)  Requested  components  will  be  used  for  the  following  purpose(s): 
(repeat  the  following  line  as  required) 


(3)  I/we  will  be  responsible  for  assuring  that  the  component(s)  or 
component  parts  will  not  be  marketed,  sold,  or  published  for  a 
profit  either  as  a  set  or  as  separate  entities  so  as  to  be  in 
competition  with  commercial  firms.  Component(s)  or  parts  can 
be  used  in  commercial  or  Government  applications/developments. 

(4)  Use  of  this  software  or  a  modified  version  will  be  made  known 
to  the  Government  when  it  is  used  on  a  Government  contract (s). 
I/we  guarantee  that  the  components  will  not  be  offered  in  sale 
to  the  Government.  If  the  components  are  modified,  expanded,  or 
improved  in  any  manner  then  only  those  resources,  e.g.,  labor 
hours,  may  be  sold  once,  and  only  once,  to  the  Government.  If 
component  are  modified,  expanded,  or  improved  using  Government 
funds-,  then  the  Government  owns  the  modified/improved  version. 

(5)  The  Government  is  neither  liable  nor  responsible  for  maintenance, 
updating,  or  correcting  any  errors  in  the  components  provided. 
Neither  is  the  Government  and  any  Government  contracted  agent 
for  development  or  distribution  of  these  component(s)  liable 

for  any  direct  or  indirect  cost  resulting  from  the  use  of  the 
component (s) .  There  are  no  warranties  of  merchantability  nor 
fitness  for  a  particular  purpose,  either  implied  or  expressed. 
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(6)  I/we  understand  that  no  material  subject  to  national  defense 
security  classification  or  proprietary  rights  was.  intended  to 
be  released  to  us.  I/we  will  report  promptly  the  discovery  of 
any  material  of  such  restriction  to  the  STARS  Repository  System 
manager  and  to  the  approving  authority.  I/we  will  follow  all 
instructions  concerning  the  use  or  return  of  such  material,  and 
will  not  further  study,  use,,  or  copy  such  material  subject  to 
security  or  proprietary  rights  markings  on  components  or  parts. 

(7)  I/we  understand  that  the  software  received  is  subject  to  export 
control  laws,  and  I/we  will  abide  by  those  regulations  as  they 
apply  to  the  component (s)  or  component  part(s)  provided  to  us. 

Signature  Date:  _  Signature  Date:  _ 


Signature  of  Requestor  Signature  of  Approving  Authority 


Name  of  the  Requestor  Name  of  the  Approving  Authority 


Title  of  Requestor  Title  of  the  Approving  Authority 


Organization  of  Requestor  Organization/Location  of  Authority 


Mailing  Address  of  Requestor  Mailing  Address  of  Authority 


City,  State,  and  Zip  Code  City,  State,  and  Zip  Code 


-  Completed  by  Repository  System  - 

Requestor  ID:  _  Authority  ID: 

Receipt  Date:  _  Reviewed  by: 


Figure  3.  Example  of  Component  Distribution  Form 
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The  following  is  a  sample  label  that  should  be  attached  to  all  physical 
media  that  is  distributed  to  authorized  users  when  the  material  contains 
export-controlled  technical  data.  This  same  information  will  also  be 
included  in  a  component  part  that  is  automatically  displayed  to  the  user 
when  authorized  to  browse  or  retrieve  a  export  controlled  component. 

STARS  REPOSITORY  SYSTEM 
Distribution  of  the  following  items  is  Limited 

(component  name,  repeat  as  required) 

Distribution  is  authorized  to  U.S.  Government  agencies 
and  private  individuals  or  enterprises  eligible  to  obtain 
this  export-controlled  technical  data  in  accordance  with 
regulations  implementing  Title  10,  USC  140c,  October  1987. 

WARNING:  This  document/tape  contains  technical  data  whose 

export  is  restricted  by  the  Arms  Export  Control  Act 
(Title  22  USC  2751  et  seq.)  or  the  Export  Administration 
Act  of  1979,  as  amended  (Title  50,  USC,  APP.  et  seq.) 

Violations  of  these  laws  subject  to  criminal  penalties. 

Disseminate  in  accordance  with  provisions  of  AFR  80-34. 

Figure  4.  Example  of  a  Restricted  Distribution  Label 
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B.5  USER  REGISTRATION  FORM 


This  form  is  used  to  enter  in  data  for  any  person,  regardless  of  their 
role  in  the  Repository  (  Supplier,  Manager,  Re-user,  Owner,  etc.)*  This 
information  will  be  entered  only  once  for  each  person  and  will  be  updated 
or  deleted  when  the  information  is  no  longer  valid. 

STARS  REPOSITORY  SYSTEM 
User  Registration  Form 


Name:  _ j _ _ 

(First)  (MI)  (Last) 

Title:  _  Position:  _ 

Nationality:  _  U.S. Status  _ 

Organization  Identification  Number:  _ 

Requested  User  Identification  Name:  _ 

Optional  Network  Address :  _ 

-  Completed  by  Repository  System  - 

Requested  User  Identification  Name:  _ 


Figure  5.  Example  of  User  Registration  Form 
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B.6  ORGANIZATION  REGISTRATION  FORM 


This  form  is  used  to  enter  in  data  for  any  organization  represented  in 
the  Repository.  This  information  will  be  entered  only  once  but  will  be 
updated  or  deleted  if  the  information  changes. 

STARS  REPOSITORY  SYSTEM 
Organization  Registration  Form 


Organization: 


Address : 


(City) 


(State)  (ZIP-Code) 


(Country)  (Phone  Number) 

-  Completed  by  Repository  System  - 

Organization  Identification  Number:  _ 

Qualified  Contractor  Access  Number:  _ 

Note:  The  above  registration  numbers  may  be  based  on  numbers  assigned 
to  the  attached  copy  of  DD  FORM  2245  approved  by: 

United'  States/Canada  Joint  Certification  Office 
Defense  Logistics  Service  Center,  Federal  Center 
Battle  Creek,  MI  49017-3084 

Attach  one  or  more  completed  User  Registration  forms  and 
indicate  the  primary  (and  optional  alternates)  coordinators. 


Figure  6.  Example  of  Organization  Registration  Form 
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B.7  CONTRACT  REGISTRATION  FORM 


This  form  is  "used  to  enter  in  data  for  all  contract  represented  in  the 
Repository.  This  information  will  be  entered  only  once  but  will  be  upated 
or  deleted  if  the  information  or  contact  changes. 

STARS  REPOSITORY  SYSTEM 
Contract  Registration  Form 


Contract  Number: 
Contract  Name: 


Contracting  Agency: 


Contact  Name: 
Address: 


Optional  Network  Address :  _ 

-  Completed  by  Repository  System  - 

Organization  Identification  Number:  _ 

Contract  Contact  Identification  Name:  _ 

Figure  7.  Example  of  Contract  Registration  Form 
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